конечно есть примеры "наследование нужно", но это все как правило из серии "и так сойдет"

многие популярные фреймворки завязанны на иерархии наследования

я вот тоже думал что интерфейсы - это все что нужно. но абстрактные классы для многих вещей правильнее. Они в правильном направлении ограничивают пользователя. Чтобы не сделал class LoggerAndRepo111 implements Logger, UserRepository .

ну и еще пара плюсов.

это ограничивает и от более возможного сценария.

class SomeLogger extends SomeLegacyLogger implements LoggerInterface

чтобы не могли наследоваться так глупо

ну во всех языках нет мультинаследования, да) но это какая-то весьма убогая аргументация, если честно)

если пользователь захочет отстрелить себе ноги, он и с абстрактными классами это сделает.

я вот тоже думал что интерфейсы - это все что нужно. но абстрактные классы для многих вещей правильнее. Они в правильном направлении ограничивают пользователя. Чтобы не сделал class LoggerAndRepo111 implements Logger, UserRepository .

Так это наоборот плюс, когда Interface назвается Logger и приходится думать над нормлаьным именем класса, с реализацией

но 111 это пиздец конечно, я такого не видел

Так это наоборот плюс, когда Interface назвается Logger и приходится думать над нормлаьным именем класса, с реализацией

не в этом же вопрос)

я вот тоже думал что интерфейсы - это все что нужно. но абстрактные классы для многих вещей правильнее. Они в правильном направлении ограничивают пользователя. Чтобы не сделал class LoggerAndRepo111 implements Logger, UserRepository .

в каком месте они ограничивают тебя в чем-то?)

но 111 это пиздец конечно, я такого не видел

я прикололся :) хотел !!! :)

чтобы не могли наследоваться так глупо

ты всегда сможешь глупо наследоваться

я вот тоже думал что интерфейсы - это все что нужно. но абстрактные классы для многих вещей правильнее. Они в правильном направлении ограничивают пользователя. Чтобы не сделал class LoggerAndRepo111 implements Logger, UserRepository .

пускай делает, ваще нет проблемы

и зависит от интерфейса

class SomeLogger extends SomeLegacyLogger implements LoggerInterface

мы все классы по умолчанию c final создаем(даже настройка в шторме есть такая) и если хочшеь создать без final то надо обосновывать на ревью зачем это тебе

я вот тоже думал что интерфейсы - это все что нужно. но абстрактные классы для многих вещей правильнее. Они в правильном направлении ограничивают пользователя. Чтобы не сделал class LoggerAndRepo111 implements Logger, UserRepository .

важно не то что класс реализует а на что завязан клиентский код и насколько этот класс после этого соблюдает SRP.

ну формулировка в стиле "к классу нельзя прилепить несколько абстрактных, но можно несколько разных интерфейсов" - чушь, имхо. Такой себе повод устраивать замену.

мы все классы по умолчанию c final создаем(даже настройка в шторме есть такая) и если хочшеь создать без final то надо обосновывать на ревью зачем это тебе

я тоже за final. но только если не abstract :)

если у тебя есть 2 интерфейса и один класс их реализующий, и всю работу этот класс делегирует другим, и клиентский код завязан либо на тот или другой интерфейс - не вижу проблемы

если у тебя есть 2 интерфейса и один класс их реализующий, и всю работу этот класс делегирует другим, и клиентский код завязан либо на тот или другой интерфейс - не вижу проблемы

а зачем такой класс вообще?

Да есть определённые плюсы. в тех же Exception классах. Когда именно важна зависимость от обобщения к частности.

вот да, экспшны удобно наследовать, но это чисто для группирвоки логической

а зачем такой класс вообще?

не я пример придумал)

короч по поводу "правильности" и т.д. всегда надо рассуждать в контексте использования класса.

во имя ISP и все такое

так все таки, будет ли кейс когда нужно наследование реально нужно, а копозиция не подходит?)

Кроме упорядовачивания экспшнов

мы все классы по умолчанию c final создаем(даже настройка в шторме есть такая) и если хочшеь создать без final то надо обосновывать на ревью зачем это тебе

а как вы тесты пишете?

так все таки, будет ли кейс когда нужно наследование реально нужно, а копозиция не подходит?)

А что, обычный случай, когда принцип Лисков должен соблюдаться, уже не подходит ? При наследовании он соблюдается (но не всегда). При его отсутствии — нет.

а как вы тесты пишете?

http://www.mockobjects.com/2007/04/test-smell-mocking-concrete-classes.html

то есть мокаются интерфейсы где они есть, а если их нет, то веротяно можно обойтись норм объектом

но да с этим бывают заморочки

А что, обычный случай, когда принцип Лисков должен соблюдаться, уже не подходит ? При наследовании он соблюдается (но не всегда). При его отсутствии — нет.

Почему не соблюдается? если у нас только реализации интерфейсов, то его ка краз сложно нарушить, чем когда у нас глубокие иерархии наследования

Почему не соблюдается? если у нас только реализации интерфейсов, то его ка краз сложно нарушить, чем когда у нас глубокие иерархии наследования

Если интрерфейсы не наследуются друг от друга каскадно, то тоже не соблюдается.

Потом, интерфейсы и ООП — это как-то ... немного разные вещи.

Почему не соблюдается? если у нас только реализации интерфейсов, то его ка краз сложно нарушить, чем когда у нас глубокие иерархии наследования

Представь, что все объекты у тебя должны быть подъобъектами твоего класса MyObject ... Как тебе тут интерфейсы помогут?

сделать интерфейс-маркер My

Ну и ? Сделаешь, далеее?

У тебя есть скажем 200 случаев скажем методов (функций), которые принимают MyObject. Тебе надо добавить в иерархию этих классов ещё 10 классов. Как тебе интерфейс My поможет?

А что, обычный случай, когда принцип Лисков должен соблюдаться, уже не подходит ? При наследовании он соблюдается (но не всегда). При его отсутствии — нет.

лисков про контракты а не про наследование

ну то есть ты и с интерфейсами тот же LSP обязан соблюдать

У тебя есть скажем 200 случаев скажем методов (функций), которые принимают MyObject. Тебе надо добавить в иерархию этих классов ещё 10 классов. Как тебе интерфейс My поможет?

я помечу эти 10 класов интерфейсом My и реализую в них методы если есть какие то. И все будет хорошо

ну мол подтипы не только через наследование можно мутить же)

У тебя есть скажем 200 случаев скажем методов (функций), которые принимают MyObject. Тебе надо добавить в иерархию этих классов ещё 10 классов. Как тебе интерфейс My поможет?

если у тебя 200 случаев когда на вход MyObject приходит - есть мысль что что-то пошло не так и эти методы должны быть прямо в MyObject а дальше скорее всего его надо будет дробить)

Потом, интерфейсы и ООП — это как-то ... немного разные вещи.

точно так же как наследование и ооп

ну мол подтипы не только через наследование можно мутить же)

Ну, расскажи, как ещё.

Я вот сходу так не помню.

Ну, расскажи, как ещё.

имплементация интерфейсов - подтипы, протоколы - те же контракты (ну то есть например у тебя есть 2 сервиса которые общаются по http и есть разные имплементации этог осервиса). То есть интерфейсы/протоколы могут быть менее явными

если у тебя 200 случаев когда на вход MyObject приходит - есть мысль что что-то пошло не так и эти методы должны быть прямо в MyObject а дальше скорее всего его надо будет дробить)

Я как бы специально абстрагировался от случая принадлежности методов классу. Это для данного случая не важно.

Я как бы специально абстрагировался от случая принадлежности методов классу. Это для данного случая не важно.

ну тогда я не понимаю что именно ты хочешь)

короч мне не нравится обсуждать абстрактный коней тем более когда они пахнут как факап с декомпозицией

имплементация интерфейсов - подтипы, протоколы - те же контракты (ну то есть например у тебя есть 2 сервиса которые общаются по http и есть разные имплементации этог осервиса). То есть интерфейсы/протоколы могут быть менее явными

Ну да, но реализация интерфейса —частный случай наследования (более специфическая форма), Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс My. Положим, код так написан, и используемый язык этого требует.

короч мне не нравится обсуждать абстрактный коней тем более когда они пахнут как факап с декомпозицией

Ты хочешь поговорить об этом в чате про абстрактный ООП? Нуну...

у меня ООП вполне конкретный) message passing и late binding)

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

> но реализация интерфейса —частный случай наследования следует различать наследование включающее в себя наследование стэйта и варианты где оно отсутствует.

когда мы поведение наследуем - то да, разницы между extend/implements нет

Ну да, но реализация интерфейса —частный случай наследования (более специфическая форма), Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс My. Положим, код так написан, и используемый язык этого требует.

реализация интерфейса, это лишь обязательство реализовать набор методов с их сигнатурами. А наследование класса, это нарушение его инкапсуляции(для наследника) + плотная завязка на внутренности реализации родителя. По мне так разница колоссальна и нельзя говорить что реализация интерфейса частынй случай наследования

Представь, что все объекты у тебя должны быть подъобъектами твоего класса MyObject ... Как тебе тут интерфейсы помогут?

мне тут ничего не поможет потому что уже все пошло не так

реализация интерфейса, это лишь обязательство реализовать набор методов с их сигнатурами. А наследование класса, это нарушение его инкапсуляции(для наследника) + плотная завязка на внутренности реализации родителя. По мне так разница колоссальна и нельзя говорить что реализация интерфейса частынй случай наследования

если выкинуть protected то инкапсуляция не рушится

реализация интерфейса, это лишь обязательство реализовать набор методов с их сигнатурами. А наследование класса, это нарушение его инкапсуляции(для наследника) + плотная завязка на внутренности реализации родителя. По мне так разница колоссальна и нельзя говорить что реализация интерфейса частынй случай наследования

Э... у тебя очень специфическое понимание ООП.

> Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс My. Что значит ссылка на объект? Ссылки ка краз и дает использование композиции, а в случае наследования ты получаешь кастомизированную вресию Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс MyObject

Э... у тебя очень специфическое понимание ООП.

может это у тебя?)

> Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс My. Что значит ссылка на объект? Ссылки ка краз и дает использование композиции, а в случае наследования ты получаешь кастомизированную вресию Ну и ещё раз, мне нужно иметь ссылку на MyObject, а не на интерфейс MyObject

В МЕСТЕ ИСПОЛЬЗОВАНИЯ ОБЪЕКТА ДОЛЖНА БЫТЬ ССЫЛКА (указатель, объектная ссылка, переменная) ТИПА MyObject.

В МЕСТЕ ИСПОЛЬЗОВАНИЯ ОБЪЕКТА ДОЛЖНА БЫТЬ ССЫЛКА (указатель, объектная ссылка, переменная) ТИПА MyObject.

можешь еще раз с начала что именно мы обсуждаем?

ERROR: S client not available

может это у тебя?)

не, у меня нормально

если выкинуть protected то инкапсуляция не рушится

могут еще быть public методы котоыре исползуютя внутри класса) но эт уже я за уши приятнул

я пока понял что у тебя есть система где все объекты являются подтипами MyObject

можешь еще раз с начала что именно мы обсуждаем?

По истории погляди, там всё видно.

могут еще быть public методы котоыре исползуютя внутри класса) но эт уже я за уши приятнул

ммм тут больше вопрос связанности а не инкапсуляции (ну то есть information hiding все плохо, а с инкапсуляцией все хорошо)

По истории погляди, там всё видно.

ничего не видно

я не понимаю что именно ты хочешь описать

Ну, значит не судьба

ну... ладно)

можешь еще раз с начала что именно мы обсуждаем?

я сказал что наследование не нужно, а Илья не согласен

я сказал что наследование не нужно, а Илья не согласен

ну вот тут опять же что подразумевается под наследованием. шаринг стэйта и protected не нужны

а само по себе наследование как вариант лепить подтипы - это и есть штука с которой можно добиться late binding по сути

но то как это реализовано в конкретном языке это уже детали

ммм тут больше вопрос связанности а не инкапсуляции (ну то есть information hiding все плохо, а с инкапсуляцией все хорошо)

так information hiding одна из двух состовляющих инкапсуляции. information hiding + объединение данных и методов для работы с ними

я так понимаю инкапсуляцию

так information hiding одна из двух состовляющих инкапсуляции. information hiding + объединение данных и методов для работы с ними

http://wiki.c2.com/?EncapsulationIsNotInformationHiding

Как вы думаете, есть ли ситуации, в которых наследование предпочтилтельнее композиции? Прост на медиуме часто статьи в духе "Наследование не нужно", а в комментах чуваки пишут что автор просто не умеет им пользовать, но примеров не приводят как правило

Есть Liskov substitution principle. S - подтип T тогда, когда для всякого модуля P использующего S можно безопасно заменить S на T и ничего не регрессировать при этом. Держа в уме этот принцип, можно делать что угодно, но практика показывает, что через наследование этот принцип нарушить в разы проще чем через композицию.

я сказал что наследование не нужно, а Илья не согласен

Нет. Ты просил пример, когда наследование нужно

Нет. Ты просил пример, когда наследование нужно

но этот пример только показывает что наследование не нужно, нет?

а само по себе наследование как вариант лепить подтипы - это и есть штука с которой можно добиться late binding по сути

У тебя каша в башке. Надо переварить

а началось всё с наркоманской идеи о превосходстве абстрактных классов над интерфейсами...)

У тебя каша в башке. Надо переварить

может у тебя?)

Есть Liskov substitution principle. S - подтип T тогда, когда для всякого модуля P использующего S можно безопасно заменить S на T и ничего не регрессировать при этом. Держа в уме этот принцип, можно делать что угодно, но практика показывает, что через наследование этот принцип нарушить в разы проще чем через композицию.

Ничего не перепутал?

а началось всё с наркоманской идеи о превосходстве абстрактных классов над интерфейсами...)

Так это ж почти одно и то же...

Ничего не перепутал?

все корректно

Так это ж почти одно и то же...

если мы говорим о плюсах - то да

Ничего не перепутал?

Поясни

абстрактный класс без стэйта ~= интерфейс

Поясни

Так ты написал, ты и поясняй... По-моему так всё ровно наоборот...

Так ты написал, ты и поясняй... По-моему так всё ровно наоборот...

то есть с композицией проще нарушить LSP чем с наследованием?

абстрактный класс без стэйта ~= интерфейс

Ну, вот, что-то в твоей голове всё же верно.

то есть с композицией проще нарушить LSP чем с наследованием?

Да.