Я как-то попробовал начать с того, что стоит различать наследование реализации и наследование интерфейса.
Превое это, в основном, такой особеннй способ переиспользования. Второе -- хм, "релиазция контракта" или как-то так.
Вроде бы были довольны и даже оживились как-то.
Здравствуйте, BlackEric, Вы писали:
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил.
Наследование — это:
— способ реализации параметрического (по одному аргументу) run-time полиморфизма во многих языках;
— удобный способ повторного использования кода в этих же языках.
Т.е. ты прав, а они нет.
BE>В пример начинаю приводить декоратор, C# extension methods и .т. д.
Лучше было бы спросить примеры у них для объяснения тобой.
Тогда хоть можно было попытаться догадаться, каков конкретно у этих гавриков взгляд на вещи. ))
Здравствуйте, Cyberax, Вы писали:
BE>>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. C>Чтобы скрытно увеличить связность и добавить неочевидные взаимодействия. Украсить случайными перекрытиями функций базового класса.
Это верно для любого способа реализации параметрического полиморфизма.
Даже как оно есть в функциональных языках, типа Хаскеля.
Предлагаешь от параметрического полиморфизма отказаться вовсе? ))
Здравствуйте, Privalov, Вы писали:
C>>Украсить случайными перекрытиями функций базового класса. P>Или намеренными. Мне приходилось видеть, когда используют наследование только потому, что в наследуемом классе есть подходящий метод. Повбывав бы.
Удачность дизайна тут ортогональна характеристикам инструмента. Налепить фигни можно в любой технике.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Cyberax, Вы писали:
BE>>>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. C>>Чтобы скрытно увеличить связность и добавить неочевидные взаимодействия. Украсить случайными перекрытиями функций базового класса.
V>Это верно для любого способа реализации параметрического полиморфизма. V>Даже как оно есть в функциональных языках, типа Хаскеля. V>Предлагаешь от параметрического полиморфизма отказаться вовсе? ))
Здравствуйте, iZEN, Вы писали:
BE>>>>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. C>>>Чтобы скрытно увеличить связность и добавить неочевидные взаимодействия. Украсить случайными перекрытиями функций базового класса.
V>>Это верно для любого способа реализации параметрического полиморфизма. V>>Даже как оно есть в функциональных языках, типа Хаскеля. V>>Предлагаешь от параметрического полиморфизма отказаться вовсе? ))
ZEN>"Объектно-ориентированное вранье" — https://www.youtube.com/watch?v=lfdAwl3-X_c
Зачем эта ссылка?
Чувак в глубоко взрослом возрасте узнал, что существует не единственный канон ООП. Он до этого не видел ни Smalltalk, ни Erlang, ни ещё десяток подобных средств, и впал в религиозный экстаз от того, что увидел что-то новое. OK, бывает. Потом он вдруг от этого переходит к неизменяемым объектам (причём говорит вроде по-русски, но слово "неизменяемый" ему неизвестно), несмотря на то, что в ООП системы "класс это нечто со своим поведением, а не свалка данных" неизменяемость практически бесполезна.
Потом он критикует статические методы, хотя любому, кто учил Java хотя бы день, понятно, что это просто метод группировки методов в некоторую позицию в иерархии, и что отсутствие объекта является неизбежным в ряде случаев (а привязывать к нему объект только ради группировки — от дурной головы ногам работа).
А потом вообще понёсся методом совы — "станьте ёжиками, моя стратегия рулит".
Я рад за него, что во взрослом возрасте он не разучился удивляться и оформлять своё удивление понятными словами, но лучше всего это описывается одной старой фидошной фразой — "Национальное русское блюдо — каша в голове".
А самое главное — при чём тут наследование? Я видел много критики наследования (точнее, наследования реализации, если быть строгим), но я не увидел ни единого пункта критики наследования и параметрического полиморфизма.
Сдаётся мне, коллега, что Вы или промазали ссылкой, или просто кинули наобум...
Здравствуйте, netch80, Вы писали:
N>Сдаётся мне, коллега, что Вы или промазали ссылкой, или просто кинули наобум...
Признаю — промахнулся.
Но Егор многим открыл глаза на философию неправильного применения ООП: объекты как структуры данных с нарушенной инкапсуляцией (JavaBean) и применением (POJO). Тут задумаешься, что вообще происходит в последние 20 лет с ООП и Java, в частности. Нужны ли эти нагромождения "костылей" из ООП (инкапсуляция, которой нет, наследование, которое стараются избегать, и полиморфизм, который не нужен) ради всего-то — эмуляции процедур?
Здравствуйте, BlackEric, Вы писали:
BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил.
Садись, два!
Принцип Барбары Лискоф. Если его понятно описывать, то класс можно разширять наследованием, но не переопределять. Есть знаменитый пример сложности этого правила — что должно наследоваться, класс квадрата от прямоугольника, или наоборот. В действительности — не то и не другое. К примеру, программист использующий класс прямоугольника и которому подсунули квадрат, будет ожидать что у него для изменения ширины не будет изменяться длина, и наоборот.
Здравствуйте, BlackEric, Вы писали:
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
BE>Что-то я не могу даже нагуглить какой ответ там ожидался.
Для реализации отношения is, т.е. sub type. Уточнение типа. Надо смотреть всякие принципы замещения Лисков, АТД и контракты.
В ООП класс это двойственная вещь, это и тип, и модуль. Модуль — расширяем. Тип — уточняем. Но все еще интереснее. Экземпляр тоже является и модулем, и типом. От него так же можно наследоваться.
Здравствуйте, vmpire, Вы писали:
BE>>Что-то я не могу даже нагуглить какой ответ там ожидался. V>У меня завтра как раз собеседование, вот и спрошу кандидата
Здравствуйте, iZEN, Вы писали:
ZEN>"Объектно-ориентированное вранье" — https://www.youtube.com/watch?v=lfdAwl3-X_c
Товарищ смешал в кучу всё: как библиотеки Java, так и паттерны проектирования.
При этом, очень похоже, что именно паттернов он толком и не знает
P.S. Приёмы ООП — это только инструмент для решения задачи.
Этот инструмент можно применять правильно, а можно и НЕправильно...
Здравствуйте, ylem, Вы писали:
Y>Я как-то попробовал начать с того, что стоит различать наследование реализации и наследование интерфейса. Y>Превое это, в основном, такой особеннй способ переиспользования. Второе -- хм, "релиазция контракта" или как-то так.
+100500
Первое — это один из вариантов повторного использования кода.
Второе — это путь уменьшения сильной связности (определить только идеи, но не их реализацию).
Можно сказать, что наследование решает две, в чём-то даже противоположные задачи...
Y>Вроде бы были довольны и даже оживились как-то.
