Что дает принцип Лисков?

ничетынепонимаешь! реализация сама интроспекцирует код реализации на io и сама будет знать что делать. io отличный язык? Вы хотите поговорить о боге нашем io и о пророке его анонiмусе?

Представь себе двигатель. Его задача крутить вал. Но он - сложный объект, состоит из многих объектов со сложной логикой сборки. Никому и в голову не придет конструировать двигатель, который не только крутит вал но и сам себя умеет собирать. И перекладывать ответственность по сборке двигателя на его клиентов - плохое решение. Двигатель умеет крутить вал, клиенты знают как заставить его крутить вал, а собирают двигатель на заводе. Паттерн строитель для того же самого.

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

приватное наследование в C++

Одиночка и глобальный объект? Ман, если у тебя есть глобальный объект, ты реализуешь паттерн Одиночка через него. Если нет - найдешь другой способ. Как ни крути, когда логика предметной области требует, чтоб некоторые сущности/службы были в единственном экземпляре, ты будешь использовать паттерн Одиночка. Хочешь ты этого или нет, осознаешь ты это или нет, независимо от того, что ты думаешь по этому поводу. Только по-разному реализуешь его в зависимости от языка и обстоятельств.

Без проблем, охотно верю:-)

как-то разбирал его, так и не понял, нахрен он нужен, простейшая логика

Строитель - очень полезная и удобная вещь. Наиболее толково разжевано в книжке «банды четырех»

анонiмус — теоретик, не написавший еще ничего сложнее хеловорда. Какой нах строитель?

Например, паттерн «Строитель», как-то разбирал его

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

так и не понял, нахрен он нужен

Ты, наверное, думаешь, что это офигенный критерий. В GoF показаны простые примеры, на них сложно увидеть пользу от паттернов, зато ее хорошо видно, если ты с этим сталкивался на практике, что еще раз подтверждает, что ты не имеешь отношения к разработке ПО. Конкретно про шаблон Строитель там, ЕМНИП, описан достаточно распространенный случай: поддержка печати в разных форматах. По нашей системе могу судить, что поддерживать это без чего-то типа Строителя не то что сложно, но это постоянная работа почти на пустом месте. Постоянно сопоставлять печать документов в разных форматах. Если реализуешь поддержку фичи одного формата, то реализовать нечто подобное в другом формате либо забудешь, либо забьешь. В итоге форматы разъезжаются, один формат становится приоритетнее других и развивается стремительнее. А ты фантазируй дальше про три строки, тебе же не разрабатывать ПО.

теоретик helloworld-а - тоже достойная должность в общем-то

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

Успешно лечится бритвой Оккама ...

ну да, ему давно предлагали вдоль.

Она усложняется именно потому, что хомячки думают что принцип Лисков __нужен__. Алан Кей ни о каких Лисков понятия не имеет.

Просто любопытно: как ты себе «авторитетов» выбираешь? Ну то есть тебе кажется правильным то, что говорит Алан Кей - в итоге ты везде его упоминаешь и считаешь его слова истиной в последней инстанции. Принцип Лисков наоборот не нравится - она становится у тебя «кухаркой» и т.д.

Ведь забавная штука - если бы Кей сказал что-то против Io, ты бы его тут же поехавшим маразматиком объявил.

сопричастности и избранности

Кстати, в контексте этого вопроса становится понятен вопрос того же анонiмуса про параметрический полиморфизм.

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

Конечно же тут становится нужен параметрический полиморфизм - фактически, это единственный инструмент из двух, который нам остаётся.

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

Тогда становится ясен и механизм выбора авторитета - сначала мы догматически отказываемся от всего многообразия инструментов ООП, оставляя себе только один, а потом ищем именитого человека пропагандирующего именно этот инструмент.

Главное не обращать внимания ни на что другое, не пытаться понять или освоить никакой другой инструмент даже если гуру и упомянет о нем. До конца стоять на своей догме!

Допустим, «клиентский» код не может рассчитывать на эти контракты, и для типа и подтипа нужно делать разных клиентов. Ну и что с того?

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

Как это осложняет проектирование?

Отсутствие четких контрактов означает, что тебе тяжело будет делать наследников.

Отсутствие гарантий интерфейса означает, что тебе придется учитывать на клиентах кучу нюансов.

А теперь представь, что в твоей системе много наследников этого класса. И много клиентов.

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

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

Процедурный код упрощал добавление новых функций без изменения существующих структур данных, но осложнял добавление новых структур данных. ОО-код упрощал добавление новых классов (через наследование поведения) но усложнял добавление новых функций.

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

Конечно функциональщина с динамической типизацией немного упрощала дело, но она не была распространена.

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

Принцип Лисков касается только одного из этих полюсов - а именно ОО-программирования и наследования поведения. Если анонiмус догматик другого полюса - процедурного, возможно он никогда не посмотрит на многообразие методов между ними.

ох ты ж CLU

у вас прошлое альтернативное.

по времени появления(не по прогрессивности, а вот ) процедурное(начало 50ых) функциональное (конец 50ых) обьектное(середина 60ых)

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

LSP как раз говорит о втором — в интерфейсе нет реализации, которую может поломать наследник. Что, впрочем, не мешает закрепить инварианты в документации на интерфейс.

Принцип Лисков касается только одного из этих полюсов - а именно ОО-программирования и наследования поведения.

LSP легко натягивается на duck typing.

Спасибо, Кэп!

Процедурный код упрощал добавление новых функций без изменения существующих структур данных, но осложнял добавление новых структур данных. ОО-код упрощал добавление новых классов (через наследование поведения) но усложнял добавление новых функций.

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

добавление новых функций без изменения существующих структур данных

Приведи пример, где ООП подход, хотя бы в теории может это осложнить.

Как ни крути, когда логика предметной области требует, чтоб некоторые сущности/службы были в единственном экземпляре, ты будешь использовать паттерн Одиночка

А кто мешает просто пользоваться одним и тем же объектом, и не создавать новые?

Конкретно про шаблон Строитель там, ЕМНИП, описан достаточно распространенный случай: поддержка печати в разных форматах.

Почему разные сабклассы не могут отвечать за разные форматы без строителя?

По моему, принцип лисков заставляет оставлять неизменными как интерфейсы, так и реализации. Расширять ты можешь, а менять нет. Это, кстати, ИМХО, сильное ограничение полиморфизма.

Во-первых, итоговый объект может быть иммутабельным. Во-вторых, никто не говорит, что нужно отказываться от простой иерархии классов в пользу Строителя. В-третьих, тут в соседнем треде обсуждают альтернативы конструктору с большим количеством параметров, Строитель - один из них.