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

Я написал так как я считаю. И я почти что цитирую Clean architecture. Ты несогласен, но не аргументируешь. Все еще считаешь что я тебе чето должен пояснять?

ГДЕ?

Да почему я-то должен приводить аргументацию против чужой гипотезы? Путь лучше автор гипотезы приводит аргументацию ЗА свою гипотезу.

о чем спор?

о чем спор?

как всегда) чей ООП длиннее)

У меня ООП 20!

и какая связь между композицией и наследованием? :)))

и какая связь между композицией и наследованием? :)))

Ох уж отнаследовавшись то, да заоверрайдив два метода из трех по любасу LSP гарантируется, ага.

LSP при этом нарушаться не будет. Будет лишь возможно наблюдаться нежелаемое поведение.

LSP при этом нарушаться не будет. Будет лишь возможно наблюдаться нежелаемое поведение.

LSP при этом нарушаться не будет. Будет лишь возможно наблюдаться нежелаемое поведение.

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

class Foo extends Bar { public function doStuff() { throw new Exception('LSP is fo pussies') } }

Ну, тогда расскажи, что у тебя за LSP

эм, лсп не нарушен

ЭЭЭЭ, так LSP как-раз про то, чтобы нежелаемого поведения НЕ было )))

регламентирует тип, а не коментарий к нему

У меня стандартый, почитай в википедии напр.

хорошо когда нет сабтайпинга

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

контракт нарушен, сигнатуры не нарушены

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

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

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

мы говорим о коде, а не о домыслах

Не путай нежелательное поведение и невалидную программу.

Ты в курсе что такое square rectangle problem? Квадратик тоже можно сделать наследничком прямоугольника, и это будет даже валидная программа. Только вот не всегда он не будет нарушать LSP

код компилится - значит все хорошо с сингатурами. То что в рантайме поведение некорректное - это уже нарушение контракта

контракт должен быть отражен в коде. то, что написано в комментарии - какой-то недоконтракт.

вообще говоря я, затеяв этот спор наследование предполагал ТОЛЬКО абстрактных классов и ТОЛЬКО реализация абстрактных методов.

увы

да. но надо стараться. @NotNull и т.д. :)

контракт должен быть отражен в коде. то, что написано в комментарии - какой-то недоконтракт.

нарушает LSP или нет - зависит от того какого контракта хотят клиенты этого кода

ну я понял, тут собрались любители DbC и AOP

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

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

вообще, я на вашей стороне. как я уже обьяснил, я за наследование, но только абстрактных классов и реализуя только абстрактные методы.

Так а в чем плюс такого подхода перед интерфейсами?

Так а в чем плюс такого подхода перед интерфейсами?

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

нарушение лсп и возможности тайпсистемы языка немного не одно и тоже

но суть именно в этом, не?

но суть именно в этом, не?

но суть именно в этом, не?

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

нету никаких плюсов) вот прям совсем никаких)

оно в итоге вынуждает использоать композицию вместо наследования :)

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

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

и даже не намекает на сие

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