Python-сообщество

Rodegast
Если тебе приходится в рантайме менять базовый класс

Когда у меня агрегация вместо наследования, мне вообще не надо с классами заморачиваться. Мне просто о них не надо даже думать. То есть иерархия классов остаётся чистой, но дела разные делаются свободно.
Походу, и в Go из-за этого наследования нет.

Rodegast
базовый класс

А что ты называешь базовым классом?

Это вам на почитать (я-то в книжке прочитал это недавно :) )
https://tproger.ru/translations/inheritance-and-composition-in-java/
https://javarevisited.blogspot.ru/2013/06/why-favor-composition-over-inheritance-java-oops-design.html

Отредактировано py.user.next (Окт. 4, 2017 14:59:54)

py.user.next
Наследования избегают

Это делают только отмороженные на всю голову граждане в промежутках между порциями галоперидола живущие в мире розовых пони. Конкретно с тобой спорить бессмысленно. Ужасно то, что тебя читают новички и по неволе впитывают флюиды твоего неадеквата.


Для тех, кто уже успел немножечко впитать. Ребята, не слушайте дядю, у дяди к вечеру поднимается давление. Наследование и агрегация - это разные не взаимозаменяемые понятия. Наследование используют тогда, когда нужен новый тип сущностей, расширяющий и/или уточняющий существующий тип. Агрегация применяется тогда, когда некий тип сущностей является составной частью другого типа сущностей. И ни как агрегация не может быть заменой наследованию. Более того, на многих языках невозможно “избегать наследования” в принципе. Еще более того, целые фреймворки построены на широком применении наследования (Django CBV как пример). Намного более того, именно наследование обеспечивает такой всеми нами любимый полиморфизм, ковариантность, типобезопасность и прочие радости бытия без наркотиков.

FishHook
Наследование используют тогда, когда нужен новый тип сущностей, расширяющий и/или уточняющий существующий тип.

Инкапсуляция нарушается. Производный тип начинает фиксировать базовый тип, связывая код. Код производного класса влияет на код базового класса. Ты понапишешь на производном классе кучу кода, а потом вдруг ты поймёшь, что базовый класс надо изменить немного. И ты не сможешь его изменить вообще. Будешь сидеть в своей программе с легаси.

FishHook
Агрегация применяется тогда, когда некий тип сущностей является составной частью другого типа сущностей.

Да ты почитай, как это делается. Когда тебе нужно создать новый тип и у тебя тянутся руки к наследованию, остановись. Сделай обёртку и пробрось методы просто. И у тебя будет новый функционал, но при этом никакого изменения иерархии классов не будет.

FishHook
Еще более того, целые фреймворки построены на широком применении наследования (Django

А Django стал идеальным? А могут они его поменять сейчас? Нет, архитектура зафиксирована. То есть убрать метод какой-то они у же не могут, поменять его сигнатуру - тоже. Всё, кина не будет, теперь оно будет состариваться только.

FishHook
наследование обеспечивает такой всеми нами любимый полиморфизм

Да прям уж там. Полиморфизм обеспечивается через интерфейсы и их реализацию.
Полиморфизм - это когда ты в функцию, которая запускается действия у кошки, передаёшь собаку и всё работает правильно. А почему? А потому что объект, с которым идёт работа, абстрагирован. А при чём тут наследование? его тут вообще нет.

Отредактировано py.user.next (Окт. 4, 2017 15:41:29)

> Когда у меня агрегация вместо наследования, мне вообще не надо с классами заморачиваться.

Зато тебе надо заморачиваться с агрегацией

> А что ты называешь базовым классом?

Ты не знаешь что такое базовый класс? Тогда почитай, может пригодится: Your text to link here…

Rodegast
Ты не знаешь что такое базовый класс?

Базовый класс - не тот, что в самом верху иерархии.

> Базовый класс - не тот, что в самом верху иерархии.

Ну это и так ясно, в самом верху object

Rodegast
Если тебе приходится в рантайме менять базовый класс

А базовый класс тут ни при чём. Я имею в виду, что когда ты отнаследовался, то этот новый класс во время выполнения фиксируется так, как описан. А с агрегацией ты можешь в любой момент поменять у экземпляра его поведение прямо во время выполнения.

Просто представь, что класс пишет в какой-то файл, который при создании экземляра открывается и при удалении экземпляра закрывается. Как запретить ему это делать, когда ты уже всё запустил? Вот ты хочешь заменить этот файл на сеть, что у тебя для этого есть? Ничего. А что даёт агрегация? Я просто этому объекту, к которому прикручен файл, снаружи гововорю “подмени файл на сеть”, он его подменяет и этот экземпляр даже не замечает этого, а начинает данные в сеть пересылать.

Ты как-то там наследовался, а я просто прикрепил к классу объект снаружи. И мне не нужно знать, а что там за файл внутри у родительского класса, а как он там привязан, а есть ли он там вообще. Я просто могу с ним отдельно снаружи взаимодействовать. При этом и прикрепить изначально я могу сразу сеть. А при наследовании? А при наследовании ты будешь очень много думать, возможно ли его заменить вообще на сеть, потому что класс у себя внутри что-то там закрывает именно определённым способом и что для сети это может просто не подойти. Или всё заново надо будет писать в нём; и что тогда дало это наследование, если кода столько же получается? То есть даже без рантайма ты уже тонешь в куче мыслей и лишней волоките.

Отредактировано py.user.next (Окт. 4, 2017 16:46:52)

> Просто представь, что класс пишет в какой-то файл, …. Вот ты хочешь заменить этот файл на сеть

Но мы же сейчас не эту проблему обсуждаем. Человек хотел узнать как ему избавится от повторяющегося кода. Наилучший вариант в его случае это наследование, агрегация здесь явно избыточна.

Rodegast
Человек хотел узнать как ему избавится от повторяющегося кода.

Возникновение копипаста уже говорит о том, что у него там что-то неправильно в целом. Думаю, наследование тут не поможет, а ещё больше всё это (несколько похожих друг на друга классов) усугубит. Поэтому и предложил ему сразу растащить это всё в разные стороны в соответствии с новым общепринятым подходом.

py.user.next
в соответствии с новым общепринятым подходом

Вот только ни нового, ни, извините, общепринятого в этом подходе не наблюдается.
Да и использовать один подход везде просто потому, что “ИБО ВОИСТИНУ” не лучший выход.
На очень большом классе задач ассоциация (что аггрегация, что композиция, что что-т там еще новомодное*) наоборот проигрывает наследованию, как с точки зрения сопровождения кода, так и производительности.

А для данной задачи вообще обладает нулевыми преимуществами по сравнению с наследованием.

Отредактировано Slow (Окт. 4, 2017 18:29:42)