является ли класс конкретизацией интерфейса? и в какой степени?

у тебя есть LoggerInterface и некий класс OldLogger, который вообще не знает об этом интерфейсе. любой новичок тутже сделает class MyLogger extends OldLogger implements LoggerInterface.

я, видимо, сильно тупее новичка. Смысл этого примера ниасилил

Да где там контракты-то в LSP? Мешаешь всё в кучу одну...

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

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

Ну не

что не?

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

и совместимость эту можно выразить возможностью расширять пред условия, и усиливать пост условия

Изначально он про замену одной реализации другой(унаследованнлй)

а проверить это можно уже по всякому

LSP же не про проверку, а про критерии для проверки

Ну ок, как это всё влияет на предмет спора ? Наследование vs композиция?

Ну ок, как это всё влияет на предмет спора ? Наследование vs композиция?

это ты мне скажи, ты же говорил что LSP как-то по разному себя проявляет в одном и другом случае

я все еще не понял в чем суть композиции в этом споре)

про наследование я понял

является ли класс конкретизацией интерфейса? и в какой степени?

является, не знаю как степени считать для этого

является, не знаю как степени считать для этого

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

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

а потому зачем вводить это излишнее уточнение? у тебя что так что эдак будет тип и подтип

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

принцип лисков не зависит, связь между классами и интерфейсами зависит, да

если быть серьезным: принцип лисков - про подтипы и доказуемые проперти, а в разных языках разное понятие наследования

и наследование зачастую не делает подтип в математическом смысле, а лелает какую-то фигню

да, есть много языков, которые разрешают стрелять в ноги

я все еще не понял в чем суть композиции в этом споре)

Инициатор (Артур, если не ошибаюсь) всего лишь попросил привести пример, когда КОМПОЗИЦИИ нужно предпочесть НАСЛЕДОВАНИЕ.

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

и это только uml

а в языках конкретных еще хуже)

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

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

вопрос неверный, но он возник

Инициатор (Артур, если не ошибаюсь) всего лишь попросил привести пример, когда КОМПОЗИЦИИ нужно предпочесть НАСЛЕДОВАНИЕ.

и ты привел ситуацию когда у тебя все объекты наследуются от MyObject, разве нет?

вопрос неверный, но он возник

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

и какой вопрос адекватный в данном месте? :)

и какой вопрос адекватный в данном месте? :)

а что нужно то от квадрата и от прямоугольника?

ну блин, на вопрос "можно ли наследовать квадрат от прямоугольника" ответ как бы "зависит от контракта прямоугольника и квадрата"

скорее всего тебе где-то нужно площать а где-то манипулировать размерами, и для манипуляции разные контракты уже

и ты привел ситуацию когда у тебя все объекты наследуются от MyObject, разве нет?

Да

скорее всего тебе где-то нужно площать а где-то манипулировать размерами, и для манипуляции разные контракты уже

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

что такое квадрат и что такое прямоугольник?

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

Это зависит от предметной области

Да

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

это не зависит от предметной области)

Но если нужно изменять сторону, то не получится

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

Угу

Угу

....ладно, проехали, нихера тогда не понял

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

это не зависит от предметной области)

Зависит. Если у тебя у квадрата нет площади и методов изменения сторон то все ок

Требование соблюдать LSP вынудит тебя делать наследование. Что не ясно то?

Класс, имплементирующий интерфейс, завязан исключительно на контракт этого интерфейса. Класс, наследующий другой класс, помимо завязки на интерфейс имеет стопятцот способов явно и неявно завязаться на нутря родителя (поэтому изначально я и написал что с наследованием LSP проще нарушить - слишком большое зацепление между ними получается). А вообще выше речь шла о наследовании с оверрайдом только абстрактных методов. Возможно это - компромисс, при условии что там нет мутируемых протектед свойств. Но ИМХО так се компромисс. Зачем абстрактному классу нужно шарить какую то логику между наследниками? Не нарушен ли там случайно SRP?

Требование соблюдать LSP вынудит тебя делать наследование. Что не ясно то?

каким образом?

Требование соблюдать LSP вынудит тебя делать наследование. Что не ясно то?

вот мне не ясно как LSP вынудит меня делать наследование

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

вот и вся связь

а есть другая проблема: моделирование предметной области, оно тоже бывает неадекватным

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

в реальном мире квадрат - это прямогугольник, все ок

Ну мне еще нравится примр с птицей и пингвином. Однако если в нашей предметной области птицы не летают, то он не работает)

овал instanceof круг

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

в реальном мире квадрат - это прямогугольник, все ок

Не в реалном мире, а тогда уж в евклидовой геометрии)

в реальном мире квадрат - это прямогугольник, все ок

......

в реальном мире квадрат - это прямогугольник, все ок

контекст важен

я как раз про реальный мир, типа где люди ходют

в программировании мы решаем проблемы реальных людей, а не играемся с абстракциями

нам важно моделировать что-то "живое"

но это так)

контекст важен

важен не контекст, а адекватное моделирование

контекст ты можешь сразу сделать хреновым

и потом говорить, что у тебя такой контекст, который вынудил тебя нарушить LSP, SRP и даже KPP

ERROR: S client not available

и потом говорить, что у тебя такой контекст, который вынудил тебя нарушить LSP, SRP и даже KPP

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

дык, ты просто перефразировал "адекватное моделирование"

лучше сразу делать такой код, который не надо менять потом)

и тут дело не в ооп, а чаще в KISS

лучше сразу делать такой код, который не надо менять потом)

https://images.moviepilot.com/image/upload/c_fill,h_470,q_auto:good,w_620/dqnrdue7llwvoah3yvom.jpg

делаем прямоугольник, у которого можно менять одну сторону... первый вопрос: нафига? :)

и тут дело не в ооп, а чаще в KISS

а kiss это про information hiding, coupling, cohesion и т.д.)

делаем прямоугольник, у которого можно менять одну сторону... первый вопрос: нафига? :)

а это про yagni

KISS это про все, но в основном про вопрос: зачем ты это делаешь, если лучше бы ты этого не делал

ну yagni это перефразировано KISS

одно другому дополняет

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

темплейт метод заимплементить) и наверное все

а нет, еще прокси классы на уровне компилятора бгг

так темплейт метод тоже не нужен)

в целом да, можно заменить

а вообще лучше интерфейсы + делегирование

тайпкласы все дела

https://habrahabr.ru/post/347242/

https://habrahabr.ru/post/347242/

как то он своеобразно каплинг и кохижн описа)

https://habrahabr.ru/post/347242/

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

чото както не то

KISS так вообще не попал

как бы вы кратко описали kiss?

как бы вы кратко описали kiss?

могу картинкой

http://cdn.qacqoc.com/wp-content/uploads/2017/05/USB-Type-C-vs-USB-3.0-What%E2%80%99s-the-difference-687x350.jpg

справа - kiss соблюден, слева - много сломаных портов

а справа эт чо? О_о

чото сложное

usb c

а справа эт чо? О_о

usb type-c разумеется

usb type-c разумеется

ни разу не видел))