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

Пошел сам знаешь куда, друх!

Возможно, вы имели в виду: гидралиск

Я в названии темы написал, что я имею в виду. Вы очень инертный человек, когда нет авторитета, в один прекрасный момент высер онанимуса становится для Вас истиной в последней инстанции.

[python][CL][OOP] square is not rectangle

ANONYMOUS

Подозрительное совпадение.

Я в названии темы написал, что я имею в виду.

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

Давай про рефакторинг поговорим, что ли.

Вот у меня есть код программы, которая работу выполняет внутри кода диалога, запуская нить в operator(). А потом, захватывая лок, испускает сигналы, чтобы в главной нити (а может и не в главной) вызвать что-то из GTK+. Это жесть. Как и то, что диалог сам себя delete this'ает. И после этого ещё может код исполнять. Это просто жесть. Мне интересно, как это всё во внятный вид приводить? Руками муторно очень.

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

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

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

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

Возможно, вы имели в виду: гидралиск

В голос!

Если тебе что то не понятно — это твои проблемы.

Конечно. А если что-то непонятно тебе — это проблемы LOR'а. Мы уже поняли.

Хватит пороть чушь. Тебе в классы заглядывать все равно придется, ты должен знать реализацию хоть с соблюдением хоть без него. Если нечего сказать, просто ничего не говори, неужели это так трудно?

Заигнорил блаженного, сразу пол темы отвалилось. Полегчало:)

Тебе в классы заглядывать все равно придется

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

когда документации совсем-совсем нет

Ну так, какая разница, в документацию или в код. Описание класса смотришь. Вот и прочитаешь об изменениях.

Короче ладно, я твое мнение услышал, спорить не буду, послушаю других. Спасибо.

То есть у меня класс осуществляет обработку пакетов, у которого сто разновидностей, но сделано так, чтобы в каких-то подпакетах, вызывая функцию, например, decode(AbstractPkgDecoder apd), пакет не декодировался, а декодировался с помощью каких-то методов подтипа костыльным образом?

Или, например

abstract class AbstractEncoder {

public void encode(String path_in, String path_out) {
Path path = Paths.get(path_in);
byte[] data = Files.readAllBytes(path);
byte[] res = encode(data);
FileUtils.writeByteArrayToFile(new File(path_out), res);
}

protected abstract byte[] encode(byte[] data);

}

так в два раза больше клиентов приходится писать (если только тип и подтип). А если инваринаты работают, один клиент для всех работает правильно. В итоге работы значительно меньше выходит.

так в два раза больше клиентов приходится писать

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

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

А зачем это вообще?

для твоей наколенной поделки оно не зачем, но оно становится критически важным когда у тебя в подчинении 5к студентов/интернов/джуниоров/индусов и надо получить продукт определённого качества за определённые сроки

Хотелось бы побольше конкретики.

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

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

В общем думай и о других тоже, а не только о себе, надоел! Мне вот тоже дохрена вопросов интересно, но я отдась себе отчёт в том, что другим то эти вопросы не интересы чуть более чем полностью.

В вопросе излечения шизофрении - очевидно, ничего.

Мне без разницы кому что интересно. Кому не интересно, идут мимо, туда, куда интересно.

Лисков утверждает [сами знаете что]

ну так и пойди [сам знаешь куда]

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

Хайль, Гидра!

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

А зачем тогда вообще они тип и подтип?

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

И да, кстати, я внятного ответа на данный вопрос не нашел в гугле. Везде пишут что *так надо* *это хорошо*, но почему надо, и почему хорошо, примеров в стиле «вот было плохо, но привязали лисков и стало хорошо», или хотя бы «Алан Кей одобряе» — ничего такого нет.

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

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

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

Ну как обычно используют? Реализовали логику в классе, наследуем ее в подклассе, меняя часть реализации, либо расширяя, чтобы не дублировать код, что не понятного то?

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

Профит в том, в данном случае, что ты не пишешь лишней писанины. Для динамики профит также в использовании метаобъектов. Есть и другие профиты. ООП затевалось не ради Лисков, ИЧСХ, задолго до нее, если чо. Тут еще большой вопрос, имеет ли она вообще к этому отношение.

вот тоже верный вопрос, callbackhell

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

Я уже ответил вкратце выше. Так мы дойдем до того, что ООП сводится к принципу лисков. Смешно же.

Хочется спросить. А зачем это вообще?

Не нужен. Лично тебе разрешаю не использовать. Вообще. Могу и справку дать. Типа «анонимус разрешил анонiмусу не пользоваться принципом Лисков в своих хеловордах. Подпись, дата, ЛОР, печать».

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

тот же классический пример с прямоугольником и квадратом: любой адекватный программист получив класс ректангл будет ожидать что ему можно сделать setWidth и setHeight. ну и ясное дело сделает setWidth и setHeight. Однако если к нему пришёл квадрат, то при вычислении площади получится ошибка. Хотя всё ведёт себя так как будто должно работать. В этом и проблема. Лучше в таком случае лучше иметь возможность проверки компилятором (в смысле не делать квадрат подтипом прямоугольника), поскольку в таком случае ошибка не будет допущена.

А потом, захватывая лок, испускает сигналы, чтобы в главной нити (а может и не в главной) вызвать что-то из GTK+. Это жесть.

А что такого?

А что такого?

Соответствующие функции в GTK+ 3 объявлены устаревшими. Приложения должны работать с UI только из главной нити. Да и в GTK+ 2 работа с несколькими потоками была невнятно описана. Поэтому многие использовали эти фичи неправильно. И даже в моём конкретном случае я в одном месте нашёл лок, который захватывался совершенно зря.

Приложения должны работать с UI только из главной нити.

ого! Серьезно чтоль? вообще все иксовые, или только гтк? я в гуе ваще никак, но писал проектик с Qt и там сигналы как-то криво работали из другого потока.

Ну так все правильно, сделай из главной нити актор/стейт машину, с мейлбоксом и сообщениями. Должно упростить все по-идее.

ого! Серьезно чтоль? вообще все иксовые, или только гтк?

В GTK+ очень рекомендуется работать из основной нити, хотя если озаботиться блокировками (gdk_threads_init/gdk_threads_enter/gdk_threads_leave), то всё ещё возможно. В Xlib надо явно вызывать в начале программы XInitThreads(), а потом все вызовы оборачивать в XLockDisplay/XUnlockDisplay, иначе будет «ой». (Я так и не понял, какой смысл в этих функциях, если то же самое можно сделать в самой программе). Но можно открывать по новому соединению к X серверу для каждой нити и работать так. В XCB с нитями получше, там почти все вызовы асинхронные и проблем как в Xlib быть не должно.

проектик с Qt и там сигналы как-то криво работали из другого потока.

Вот это гуглится: http://doc.qt.io/qt-4.8/threads-qobject.html Суть довольно проста — при отсылке из другого потока надо вбрасывать сообщение в цикл целевого потока, тогда гонок не будет.

сделай из главной нити актор/стейт машину, с мейлбоксом и сообщениями.

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

В принципе, понятно, что делать, только занятие муторное.

Лисков утверждает ...

Самое смешное, что ее зовут Барбарой)

Самое смешное, что это ничего не меняет в смысле склонений. Или о чем ты?

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

«Правильного» в смысле согласованности контрактов типа и подтипов. Отсутствие такой согласованности (т.е. нарушение принципа Лисков) говорит о том, что мы имеем дело не с наследованием подтипов, а с чем-то другим, и наследования в нашем случае быть не должно!

Другими словами:

Если ( Думаем_Что_Имеет_Место_Наследование_Подтипов ) То ( Должен_Выполняться_Принцип_Лисков ).

Или

Если ( Принцип_Лисков_Не_Выполняется ) То ( Наследования_Подтипов_Нет_И_Наследование_Скорее_Всего_Применять_Нельзя ).

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

Казалось бы, если готов тип Rectangle есть соблазн применить наследование реализации, и реализовать Square как подтип Rectangle. Да, это обойдется почти без крови и без кода, наследование реализации все же...

Но вот поскольку Square это ну никаким местом не подтип Rectangle (да, именно из-за несогласованности контрактов), то от такого решения мы получим больше проблем у клиентов при повторном использовании, нежели пользы от экономии кода.

А ведь принцип Лисков в данном случае не выполняется, - не всегда Square можно подставить вместо Rectangle в клиентский код. Если бы мы пользовались этим принципом в том смысле, что описал выше, то не наступили бы на грабли и не экономили бы строчки кода с помощью наследования.

А ведь принцип Лисков в данном случае не выполняется, - не всегда Square можно подставить вместо Rectangle в клиентский код. Если бы мы пользовались этим принципом в том смысле, что описал выше, то не наступили бы на грабли и не экономили бы строчки кода с помощью наследования.

ИМХО, это как раз и означает абсурдность принципа Лисков. Вместо этого нелепого ограничения, надо просто иметь в виду, что клиент должен по разному обрабатывать квадрат и прямоугольник, либо для их обработки используется 2 клиента, и никаких проблем не будет.

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