Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование.
Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
Что-то я не могу даже нагуглить какой ответ там ожидался.
Я бы ответил, что для прокидывания интерфейса. Например, COM. Ты не знаешь что внутри, но знаешь что поддерживает тот или иной интерфейс и уже можешь работать с этим.
Здравствуйте, Amon_RA, Вы писали:
A_R>Здравствуйте, BlackEric, Вы писали:
A_R>Я бы ответил, что для прокидывания интерфейса. Например, COM. Ты не знаешь что внутри, но знаешь что поддерживает тот или иной интерфейс и уже можешь работать с этим.
Не уверен. В C++ интерфейсов нет, а наследование есть.
Здравствуйте, BlackEric, Вы писали:
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
LSP — входит в пять принципов ООП — SOLID.
BE>Что-то я не могу даже нагуглить какой ответ там ожидался.
Вот и выросло поколение ЕГЭ, избегающее думать и задумываться.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, BlackEric, Вы писали:
BE>>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
ZEN>https://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков ZEN>- входит в пять принципов ООП — SOLID.
А можно подробнее, что я не понял связь принципа подстановки и наследования.
я не заморачиваюсь и просто спрашиваю, что ожидалось услышать
правда, я и хожу, последнее время, джаст фо фан
*в большинстве случаев, долго ржу (не вслух)
про солид итд спрашивают обычно в контексте про ооп, оод, паттерны проектирования итд
хотя можно было бы ответить тип — наследование нужно для уменьшения избыточности
но это все разный угол на одну и туже точку, что ожидал в ответ собеседующий никто не узнает
1) для DRY ("Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы") — общий для разных наследников код реализуется в их предке, заодно и общие поля данных в нём описываются (обычно когда все классы пишет один программист)
2) (то что вы собственно ответили) для удобства расширения по принципу открытости/закрытости — O в SOLID (обычно когда наследников пишет уже другой программист)
Здравствуйте, iZEN, Вы писали:
BE>>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
ZEN>LSP — входит в пять принципов ООП — SOLID.
Это не причина использования наследования, а ограничение на это использование.
BE>>Что-то я не могу даже нагуглить какой ответ там ожидался.
ZEN>Вот и выросло поколение ЕГЭ, избегающее думать и задумываться.
А какое поколение отличается неумением читать вопрос и ответами на то, что не спрашивалось?
The God is real, unless declared integer.
Re: Перед этим спрашивали "Что такое наследование?"?
Перед тем как задать вопрос "Зачем нужно наследование?", спрашивали "Что такое наследование?" ?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование.
Это один из приёмов повторного использования кода. BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
Приёмов повторного использованя кода много, сравнительная эффективность сильно зависит от исполнителя, у каждого может оказаться свой любимый инструментарий. BE>Что-то я не могу даже нагуглить какой ответ там ожидался.
Нужно угадать и спеть почитаемые именно этими собоседователями мантры и паттерны.
Здравствуйте, BlackEric, Вы писали:
A_R>>Я бы ответил, что для прокидывания интерфейса. Например, COM. Ты не знаешь что внутри, но знаешь что поддерживает тот или иной интерфейс и уже можешь работать с этим. BE>Не уверен. В C++ интерфейсов нет, а наследование есть.
Если следовать классике жанра C++, то считается, что интерфейс в нём это:
1. Открытые члены класса
2. Шаблон проектирования
И то и другое в C++ легко реализуемо и по сути является базовыми понятиями. Нет лишь специального ключевого слова, как в некоторых других известных языках программирования. Хотя если брать более продвинутые реализации такие как Qt, стоит отметить, что там интерфейсы ушли далеко вперёд, в частности это хорошо видно в плагиностроении.
Здравствуйте, Amon_RA, Вы писали:
A_R>Я бы ответил, что для прокидывания интерфейса. Например, COM. Ты не знаешь что внутри, но знаешь что поддерживает тот или иной интерфейс и уже можешь работать с этим.
Это уже не просто наследование, а больше полиморфизм. Но раз уж они были упомянуты, то можно ещё спросить и про инкапсуляцию. Хотя с другой стороны зачем спрашивать. Может всё это повод задуматься, может быть наследование и не нужно вовсе и эффективнее использовать агрегирование, а то и вовсе переходить на другую парадигму программирования, то есть не ООП. По большому счёту наследование это понятие из материальной логики, именно оттуда программисты и взяли это и многое другое.
Здравствуйте, BlackEric, Вы писали:
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование.
Чтобы скрытно увеличить связность и добавить неочевидные взаимодействия. Украсить случайными перекрытиями функций базового класса.
На самом деле наследование используется для двух вещей: наследование интерфейса (и тут LSP рулит, потому что такое наследование говорит, что производный класс является и базовым тоже). Компилятор поддерживает неявное приведение производного типа к базовому.
для более базового принципа — повторного использования кода (а также закрытости к изменению и открытости к расширению). Тут используется приватное наследование (которое в том числе запрещает неявное приведение производного класса к базовому). В этом случае LSP не работает (хотя используется все то же наследование, но любители LSP такой вариант вообще не понимают, поэтому хором рассказывают сказки, что это что-то "странное" и "так делать не надо", хотя нет никаких причин не использовать инструмент там, где он подходит). Это как раз тот случай, когда квадрат можно унаследовать от прямоугольника (если наследование от Shape не требуется). Часто заменяется инкапсуляцией, потому что так понятнее.
P.S. Это все было про C++ (хотя это базовые принципы ООП, которые универсальные).
BE>Хожу я тут по собеседованиям. И вот уже дважды меня спросили зачем нужно наследование. BE>Ответ, что для расширения и переопределения функционала базовых классов их не устроил. В пример начинаю приводить декоратор, C# extension methods и .т. д.
BE>Что-то я не могу даже нагуглить какой ответ там ожидался.
У меня завтра как раз собеседование, вот и спрошу кандидата
Здравствуйте, Qt-Coder, Вы писали:
QC>Здравствуйте, BlackEric, Вы писали:
BE>>Что-то я не могу даже нагуглить какой ответ там ожидался. QC>Для уменьшения копи-паста.
Плохо продуманное наследование только увеличивает количество копипасты. "А если хочется переопределить поведение наследника, надо взять 99% кода из метода предка и вклинить свой 1% там где нужно"
Собственно, паттерны от GoF/Fowler/etc как раз об этом: набор типичный сценариев, которые появляются при вычленении сущностей, и как не накосячить с этим в своём коде.
Я как-то попробовал начать с того, что стоит различать наследование реализации и наследование интерфейса.
Превое это, в основном, такой особеннй способ переиспользования. Второе -- хм, "релиазция контракта" или как-то так.
Вроде бы были довольны и даже оживились как-то.
Здравствуйте, 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>Вроде бы были довольны и даже оживились как-то.
