-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Наследование vs Агрегация
- Автор темы HraKK
- Дата начала
ну к чему писать код, который просто повторяет все то, что класс может унаследовать, чтобы просто добавить немного нового функционала?
Alexandre, не только частный случай, но и более обширный, когда потомок реализует весь функционал родителя и добавляет свой
самый простой пример - в JavaScript (я сейчас на нем больше пишу) мы расширяем объект , добавляя в него поля и обработчики - это идеология всех библиотек, таких как Prototype, jQuery
-~{}~ 10.02.09 15:14:
ustas
+1
"все относительно"
-~{}~ 10.02.09 15:33:
сижу думаю ... в PHP слишком мало случаев наследования, нет распространенных иерархий классов, по которым можно судить
а в Java вполне распространен принцип добавления функционала в дочерних классах, переопределение методов с изменением сферы применения потомка
Alexandre, не только частный случай, но и более обширный, когда потомок реализует весь функционал родителя и добавляет свой
самый простой пример - в JavaScript (я сейчас на нем больше пишу) мы расширяем объект , добавляя в него поля и обработчики - это идеология всех библиотек, таких как Prototype, jQuery
-~{}~ 10.02.09 15:14:
ustas
+1
"все относительно"-~{}~ 10.02.09 15:33:
сижу думаю ... в PHP слишком мало случаев наследования, нет распространенных иерархий классов, по которым можно судить
а в Java вполне распространен принцип добавления функционала в дочерних классах, переопределение методов с изменением сферы применения потомка
Long
Новичок
я не помню уже писал тут или в личной беседе - аналогия "человек в холодильнике" не верна. если уж приводить аналогию, то это будет что-то типа "демона максвела".
grigori, шикарные аргумены
давайте взглянем глубюже. что есть агрегация по своей сути? это композиция некоторых объектов, которым мы будем делегировать решение тех или иных задач. т.е. если бы мы строили объект "дверь", то логично было бы агрегировать "замок", "ручку", "петли" и т.п.
что мы имеем в данной ситуации? композиция из одного объекта - это бред! тем более что наследник по своей сути полностью повторяет функции родителя - хранит объекты + вносит новые методы и свойства. т.е. никакого смысла агрегировать один объект со схожей сутью нет.
ну а если посмотреть внимательно, то в вебовских задачах практически все случаи наследования спорны. это все хорошо в теории, но на практике нужно делать так как удобнее. сейчас уже ни у кого не вызывает припадков ярости денормализация БД, например.
grigori, шикарные аргумены
давайте взглянем глубюже. что есть агрегация по своей сути? это композиция некоторых объектов, которым мы будем делегировать решение тех или иных задач. т.е. если бы мы строили объект "дверь", то логично было бы агрегировать "замок", "ручку", "петли" и т.п.
что мы имеем в данной ситуации? композиция из одного объекта - это бред! тем более что наследник по своей сути полностью повторяет функции родителя - хранит объекты + вносит новые методы и свойства. т.е. никакого смысла агрегировать один объект со схожей сутью нет.
ну а если посмотреть внимательно, то в вебовских задачах практически все случаи наследования спорны. это все хорошо в теории, но на практике нужно делать так как удобнее. сейчас уже ни у кого не вызывает припадков ярости денормализация БД, например.
Long
Новичок
HraKK, теория и практика - две большие разницы
еще раз повторяю - я считаю, что агрегация одним объектом другого при условии что их сущности пересекаются (в нашем случае - одного хранилища другим хранилищем) и других объектов не агрегируется - бред. и не надо передергивать, твои аналогии не верные, я уже писал
еще раз повторяю - я считаю, что агрегация одним объектом другого при условии что их сущности пересекаются (в нашем случае - одного хранилища другим хранилищем) и других объектов не агрегируется - бред. и не надо передергивать, твои аналогии не верные, я уже писал
Было бы это быстрым решением, этого спора не было. Спор возникает потому что Long считает это правильным решением.
Он должен являться его частью.
А вот тут ты замечательно подвел к еще одной ловушке. И так внимание... ДА! Совершенно верно Long считает что все магические методы зло, в особенности __autoload .
Long
Новичок
HraKK ты опять подменяешь понятия. я считаю что в данном случае нет единственно "правильного" решения. оба решения имеют право на жизнь и оба правильные в своей части.
и про магию ты опять подменяешь понятия - я считаю, что autoload суть goto только чуть в другом обличии. при этом __call() имеет совсем другую "природу". неужили разница не очевидна?
и про магию ты опять подменяешь понятия - я считаю, что autoload суть goto только чуть в другом обличии. при этом __call() имеет совсем другую "природу". неужили разница не очевидна?
Видимо, был горький опыт неправильного использования автолоада =)
Если в нем пробит четкий биндинг на ФС, в виде правил, а не тупо {class_name=>file} (что и правда тупо), то он мало что удобен, да еще и полезен ибо не позволяет развести помойку.
Правда, без неймспейсов временами тяжеловато, приходится извращаться с подчерками.
-~{}~ 11.02.09 02:08:
>> Было бы это быстрым решением, этого спора не было
Кстати, быстрое решение часто самое правильное: отрефакторить можно всегда, а раздумывая сутками над философскими вопросами, можно прокакать все дедлайны.
Если в нем пробит четкий биндинг на ФС, в виде правил, а не тупо {class_name=>file} (что и правда тупо), то он мало что удобен, да еще и полезен ибо не позволяет развести помойку.
Правда, без неймспейсов временами тяжеловато, приходится извращаться с подчерками.
-~{}~ 11.02.09 02:08:
>> Было бы это быстрым решением, этого спора не было
Кстати, быстрое решение часто самое правильное: отрефакторить можно всегда, а раздумывая сутками над философскими вопросами, можно прокакать все дедлайны.
Ну, мне совсем не нравится вместо человеческого DefaultController писать такую казябазю, потому юзаем смешанный подход вида Namespace_ClassName с забавным парсингом (то, что не тормозит - сами удивляемся =)). Хотя дело вкуса. Простота - это тоже хорошо.
В академическом коде я бы точно не стал наследовать.
В академическом коде я бы точно не стал наследовать.
