FishHook
зачем в нем вообще нужен класс Animal

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

Великолепно! У тебя в программе есть интерфейсы, которые сама программа не использует. Осталось только показать на примере какой-нибудь юз-кейс использования этих интерфейсов программистом.

FishHook
У тебя в программе есть интерфейсы, которые сама программа не использует.

Она их использует, просто в питоне пофиг какой тип передаётся в функцию. А вот в каком-нибудь C++ тебе надо будет от этого класса наследоваться, потому что при вызове функции, которая работает с этим интерфейсом, будет происходить проверка типа. А в питоне этого не надо делать. Ты можешь наследоваться, а можешь не наследоваться. Наследуйся в уме, короче. Не нужно стремиться к идеалу какому-то типа “всё должно использоваться, положено использоваться - должно использоваться”. Зачем тебе делать эту связь через наследование, если в питоне её можно не делать?

Объясняю для вновь вошедших.
Фабула такова: примерно полгода назад py.user.next узнал о существовании языка go, и очень негативно отзывался по его поводу, аргументируя тем, что корпорация зла Google не может сделать ничего хорошего, её цель “подсадить” программистов на иглу технологии, а потом коварно изменить лицензию и всех поработить. Но, видимо, почитав доки, наш коллега проникся идеями и теперь демонстрирует любовь к довольно противоречивому подходу, применяемому в голанге. Более того, теперь это уже “современный мир программирования”, а остальное все гавно. Еще более того, писать на других языках нужно ровно так же как на голанге. Ну и что, что в питоне нет интерфейсов, а в го есть? Надо их эмулировать, и насрать, что получаются бессмысленные куски кода, это неважно. В го нет наследования, так оно и нигде не нужно!! Вот так вот! И насрать, что в го наследование заменяется композицией структур. В питоне нет композиции структур? И ладно, пусть их не будет, главное чтобы и наследования тоже не было. А как же повторное использование, как же всякий там DRY? Ну, в голанге при композиции структур методы родителя композируются в методы потомка. Ну да, это похоже на наследование, но нет. А как в питоне то быть с его “несовременной” интерпретацией ООП? А никак! Нет ноженек - нет мультиков!

py.user.next
Она их использует

Покажи каким образом.

Не нужно стремиться к идеалу какому-то типа “всё должно использоваться, положено использоваться - должно использоваться”

Ты серьезно? Предлагаешь писать код, который никак не участвует в программе?

FishHook
Покажи каким образом.

В функции вызывается только то, что есть в этом интерфейсе. Функция вообще не знает ни про Dog, ни про Cat. Ты пойми, то, что ты видишь, что оно лежит в одном месте, это оно только здесь в одном месте лежит. В реале оно будет лежать в своих модулях. И для того, чтобы использовать эту функцию, ты должен будешь реализовать этот интерфейс в других там каких-то классах, которые лежат хрен знает где.

FishHook
Но, видимо, почитав доки, наш коллега проникся идеями и теперь демонстрирует любовь к довольно противоречивому подходу, применяемому в голанге.

Go вообще не имеет к этому отношения. Просто было интересно, почему они наследование не сделали изначально, это же типа везде есть. А потом оказалось, что сейчас все отказываются от классического ООП и встаёт вопрос “а нужно ли оно вообще?”. Ты о проблеме ромба читал? Иерархия классов создаёт проблемы.

FishHook
Ну и что, что в питоне нет интерфейсов, а в го есть? Надо их эмулировать

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

FishHook
А как же повторное использование, как же всякий там DRY?

На практике его нет. Вот у тебя виджет с кучей методов есть, например, но в своей программе ты сколько из них используешь? Ты же не должен их все пробрасывать. Ты его сагрегировал, нужные методы пробросил, используя этот виджет внутри класса, а дальше пользуешься своим классом. И никуда он не привязан, ни к какой иерархии.

FishHook
Предлагаешь писать код, который никак не участвует в программе?

Обычно его пишут и наследуются, но это наследование не является необходимым.


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

py.user.next
что сейчас все отказываются

Вот кто эти все? Вот на днях вышла девятая Джава. Не только наследование не отменили, но и вообще приватные методы в интерфейсах разрешили. А ранее впилили дефолтные реализации в интерфесы. Может быть посмотрим, как дела обстоят с дот нете? В С++? В JS? Кто эти мифические “все”?

py.user.next
Нужно реализовать в нём интерфейс итератора или интерфейс последовательности. А где тут наследование? А нигде. Поэтому утверждение о том, что без наследования нет полиморфизма, - это бред.

Это убогий подход, который работает только в скриптовых языках типа питона. В питоне объект может не реализовывать интерфейса итератора при создании, а потом внезапно взять и начать реализовывать. Просто в него добавили методов в рантайме. Интерпретатор может найти метод по имени, и таким образом решить, реализован интерфейс или нет. Это не есть гуд. Во-первых, вытягивать имена и сигнатуры методов через рефлексию для проверки на соответствие контракту - идея крайне убогая. Во-вторых, проверка на соответствие контракту в рантайме - это даже не серьезно. Тот факт, что в питоне можно так делать, не значит, что нужно. Это дичь и бред.

FishHook
Вот на днях вышла девятая Джава. Не только наследование не отменили

Как они отменят, если много кода с наследованием написано? И его надо поддерживать, продолжая в том же духе.

FishHook
Вот кто эти все?

Натрахавшиеся с иерархией классов (кто разрабатывал в классической ООП парадигме долгое время). Из той же серии разговор об однометодных классах. Если у тебя получается класс, в котором один метод, лучше сделать вместо него функцию отдельную. Хотя в классике у тебя должен быть класс, ведь от него типа может понадобиться унаследоваться. Программирование же продолжает развиваться, стили устаревают. Когда-то ведь и на Паскале все поголовно писали, а сейчас он считается старьём в плане своих возможностей.

FishHook
В JS?

Вот я в книжке по JavaScript это и прочитал. И пример там приведён. Не надо загрязнять дерево типов без нужды.

FishHook
Это убогий подход, который работает только в скриптовых языках типа питона.

Да это везде так работает. Только в языках типа Go, Java интерфейсы есть в виде конструкций. Ты точно так же имплементируешь интерфейс, чтобы сделать объект, подходящим для определённых операций. Не в рантайме, конечно, но в самом коде это так и делается.

py.user.next
Имена, дружище, имена! Конторы, известные ученые, исследовательские группы. Все - это ты и еще один дурачок с sql.ru, от серьезных людей я подобного не слышал.

Давай на примере, не про кошек и собак, а возьмем реальную задачу. На базе питоньего dict нужно реализовать классы DefaultDict и NotNoneKeyDict. Прошу продемонстрировать мастер класс. Без наследования, естественно.