Здравствуйте, Сергей Губанов, Вы писали:
СГ>У объекта сообщения Message не может быть метода DoSomething!!! СГ>У него вообще ничего нету, это абстрактный тип-пустышка = ABSTRACT RECORD END. СГ>Откуда сообщению знать как его будет обрабатывать какой-то конкретный получатель? СГ>У сообщения не может быть метода его обработки — cообщение пришло, а уж как на него реагировать — это целиком в компетенции получателя.
Хм, похоже на события в C#. Поскольку, если "абстрактный тип — пустышка", то важен сам факт получения сообщения. Только, пардон, объяснять надо, а то есть у меня такой недостаток, как незнание Oberon. А то что Вы привели, это скорее некий закос под "Visitor".
Выше уже писали про LSP в контексте данного паттерна. Все.
VD>DrawShape(shape : Shape) : void
VD>{
VD> | square is Square => DrawSquare(square);
VD> | circle is Circle => DrawCircle(circle);
VD> | _ => DoDefaultAction(shape);
VD>}
VD>
Не важно, есть pattern-matching в языке, или нет. Проблема всегда в том, сколько именно такого кода появится в программе. Если один фрагмент — не беда, если десяток, то...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не важно, есть pattern-matching в языке, или нет. Проблема всегда в том, сколько именно такого кода появится в программе. Если один фрагмент — не беда, если десяток, то...
И в чём именно проблема?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladGalkin, Вы писали:
VG>Я, собственно, в контексте только ООП его и рассматривал, т.к. человек, видимо, хотел услышать ответ применительно к ООП , однако я рад таким развернутым замечаниям и дискуссии.
Я не против ООП. Я просто хотел обратить внимание, что ООП — это тоже штампы. Осозновая это ты становишся умнее, так как будешь применять правила не как слепой верующий, а со знанием дела.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не важно, есть pattern-matching в языке, или нет. Проблема всегда в том, сколько именно такого кода появится в программе. Если один фрагмент — не беда, если десяток, то...
Конечно! Разница только в удобстве! Вот только получая это удосбтво начинаешь задумываться на тем не являются ли догмами многие "незыблимые принципы ООП".
На самом деле есть два подхода. Подход от функции и подход от объекта. Иногда удобен одни. Иногда другой. Подход от функции позволяет расширять функциональность не меняя классов. Это бывает очень полезно. Как я уже говорил, паттерн Посетитель решает ту же задачу, только очень убого.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, VladD2, Вы писали:
VD>>На самом деле это догма. IB>Это не догма, это суровая правда жизни... А когда в реальном коде сталкиваешься с нарушением принципа в вышеприведенной формулировке, то это вообще — попа, волосатая, в прыщах.
Не будь столь котегоричным. Поверь, ты просто смотришь на проблему под определенным углом.
Ну, а то что ты видишь в коде — это не более чем проявление глупости человеческой. Будучи же примененным с умом необычный подход может дать очень неожиданный результат.
VD>> А по жизни могут быть разные приоритеты. IB>Дело не в приоритетах, а в том, что код какого-нибудь левого модуля может порушить все приложение, при казалось бы совершенно корректном соблюдении контрактов. Что является архитектурным косяком и никакими приоритетами не оправдывается....
С чего бы это? Если код спроектирован разумно, то его ничто не порушит.
Вообще в ООП есть много догм. Одна из них обязательная инкапсуляция. ООП почему-то не хочет воспринимать чистые данные.
В общем, идеология всегда рождает догмы. Чтобы видить догмы нужно учить разные идеологии.
Догмы разумны в пределах одной идеологии, но никогда нельзя забывать, что есть и другие идеологии.
VD>> Например, иногда просто нет возможности ввести виртуальные члены или не хочется создавать наследников. При этом внешнее решение может оказаться очень выгодным. Кое как проблему позволяет решить паттерн Посетитель, но увы у него море своих проблем. IB>Не зацикливайся на ООП, говоря проще — код, который пользуется некоторым функционалом по заранее оговоренному контракту, не должен зависеть от конкретной реализации этого контракта.
Дык, как раз я то на ООП не зацикливаюсь.
Функции могут иметь высший приоритет, в некоторых стратегиях, а данные быть вторичными.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dottedmag, Вы писали:
D>Я прекрасно знаю разницу между subtyping и subclassing. А вам бы неплохо узнать, что в ОО-языках типы выражаются классами.
Кое-кто считает Сэлф и Руби ООЯ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
ГВ>>Не важно, есть pattern-matching в языке, или нет. Проблема всегда в том, сколько именно такого кода появится в программе. Если один фрагмент — не беда, если десяток, то...
IT>И в чём именно проблема?
Только в количестве.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Не важно, есть pattern-matching в языке, или нет. Проблема всегда в том, сколько именно такого кода появится в программе. Если один фрагмент — не беда, если десяток, то...
IT>>И в чём именно проблема?
ГВ>Только в количестве.
Ну так функционал всё равно писать надо, много его или мало.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>У объекта сообщения Message не может быть метода DoSomething!!! СГ>У него вообще ничего нету, это абстрактный тип-пустышка = ABSTRACT RECORD END. СГ>Откуда сообщению знать как его будет обрабатывать какой-то конкретный получатель? СГ>У сообщения не может быть метода его обработки — cообщение пришло, а уж как на него реагировать — это целиком в компетенции получателя.
Пардон, вчера сильно торопился домой, поэтому сейчас еще допишу, что данный код вообще кажется мне несколько странным, и непонятно
при чем тут LSP, если речь идет не о поведении соббщений, а о том, как они обрабатываются кем либо.
Здравствуйте, VladD2, Вы писали:
VD>Я не против ООП. Я просто хотел обратить внимание, что ООП — это тоже штампы. Осозновая это ты становишся умнее, так как будешь применять правила не как слепой верующий, а со знанием дела.
Ничто не следует расматривать как догму, ко всему стоит подходить с умом. Что еще тут сказать?
ЗЫ: У меня Janus падает при попытке отправить или сохранить сообщение, после того как я убрал использование tagline:
System.NullReferenceException: Object reference not set to an instance of an object.
at Rsdn.Janus.TagLineManager.FindAppropriateTagLine(TagLineInfos tagLineInfos, Int32 forumId)
at Rsdn.Janus.DatabaseManager.AddOutboxMessage(MessageInfo mi)
at Rsdn.Janus.MessageForm.SaveMessage(Boolean closeOnSave)
at Rsdn.Janus.MessageForm.WriteMessageHandler()
at Rsdn.Janus.Framework.StripEventDispatcher.DispatchEvent(String eventId)
at Rsdn.Janus.Framework.StripEventDispatcher.ClickHandler(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key,
ЗЫЗЫ: Всех с наступающим Новым Годом, счастья, здоровья etc. и интересных дискуссий на RSDN.
Здравствуйте, VladD2, Вы писали:
VD>Не будь столь котегоричным. Поверь, ты просто смотришь на проблему под определенным углом.
Нет, я-то как раз смотрю на нее шире..
VD> Будучи же примененным с умом необычный подход может дать очень неожиданный результат.
Не спорю, но это имеет мало отношения к данной теме... )
VD>С чего бы это? Если код спроектирован разумно, то его ничто не порушит.
Об этом и речь. Если код завязан на конкретную реализацию не оговоренную в контракте, то код спроектирован не разумно.
VD>Вообще в ООП есть много догм. Одна из них обязательная инкапсуляция.
Это не догма, это способ выживания.. =)
VD>ООП почему-то не хочет воспринимать чистые данные.
Вот зверюга! )
VD>Догмы разумны в пределах одной идеологии, но никогда нельзя забывать, что есть и другие идеологии.
Вот-вот, принцип Лисков служит неплохим критерием правильности дизайна, если обобщить его на контракты и реализации..
VD>Дык, как раз я то на ООП не зацикливаюсь.
Да ладно.. )
VD>Функции могут иметь высший приоритет, в некоторых стратегиях, а данные быть вторичными.
И что? Данные-то тут причем...
Здравствуйте, IT, Вы писали:
ГВ>>>>[...]Если один фрагмент — не беда, если десяток, то... IT>>>И в чём именно проблема? ГВ>>Только в количестве. IT>Ну так функционал всё равно писать надо, много его или мало.
А кто-то это отрицает?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>>[...]Если один фрагмент — не беда, если десяток, то... IT>>>>И в чём именно проблема? ГВ>>>Только в количестве. IT>>Ну так функционал всё равно писать надо, много его или мало.
ГВ>А кто-то это отрицает?
Так в чём тогда проблема?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VG>FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT
VG>Above is a paraphrase of the Liskov Substitution Principle (LSP). Barbara Liskov first
VG>it as follows nearly 8 years ago. What is wanted here is something like the following substitution property: If
VG>for each object o of type S there is an object o of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o is substituted for o then S is a subtype of T.
На самом деле, это довольно забавная подмена. Если интерпретировать более точно, то LSP постулирует, что если объект, являющийся формальным подтипом S не может быть свободно подставлен вместо объекта супертипа T, то S не является подтипом T. Даже если формально S "наследует интерфейсы" T.
Например, с точки зрения компилятора типы могут находиться в отношении "супертип-подтип", но на самом деле это будет не совсем так, поскольку иерархия не будет удовлетворять критерию подставляемости. Вот такое забавное противоречие может быть.
VG>И пример кода нарушающего этот принцип:
VG>
В смысле иллюстрации здесь не хватает одного очень важного элемента:
void DrawShape(const Shape& s)
{
if (typeid(s) == typeid(Square))
DrawSquare(static_cast<Square&>(s));
else if (typeid(s) == typeid(Circle))
DrawCircle(static_cast<Circle&>(s));
else s.Draw();
}
Если точнее, то не хватает ссылки на следование некоему контракту, предоставляемому базовым классом. Если этой строчки нет, то нарушение LSP не иллюстрируется, поскольку сам критерий Лисковой определён для ситуаций, когда программа строится на контрактах супертипов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IB, Вы писали:
VD>>Не будь столь котегоричным. Поверь, ты просто смотришь на проблему под определенным углом. IB>Нет, я-то как раз смотрю на нее шире..
Тебе кажется.
VD>> Будучи же примененным с умом необычный подход может дать очень неожиданный результат. IB>Не спорю, но это имеет мало отношения к данной теме... )
Прямейшее. Просто ты не можешь это осознать.
VD>>С чего бы это? Если код спроектирован разумно, то его ничто не порушит. IB>Об этом и речь. Если код завязан на конкретную реализацию не оговоренную в контракте, то код спроектирован не разумно.
Контракты и интерефейсы тоже догмы той идиологии которую ты считашь единственно верной. Меж тем есть другие которые во многих случаях могут оказаться быолее эффективными.
VD>>Вообще в ООП есть много догм. Одна из них обязательная инкапсуляция. IB>Это не догма, это способ выживания.. =)
Это чистейшая догма. Если понимать это, то и она будет применяться разумно. Если нет, то будет однобокое мышление.
VD>>ООП почему-то не хочет воспринимать чистые данные. IB>Вот зверюга! )
Ага. И что забавно очень часто совершенно напрасно. Проектировать в ОО-стиле все подряд не эффективно. ООП не панацея.
VD>>Догмы разумны в пределах одной идеологии, но никогда нельзя забывать, что есть и другие идеологии. IB>Вот-вот, принцип Лисков служит неплохим критерием правильности дизайна, если обобщить его на контракты и реализации..
Это прицип применим только при очень большом количестве "но". Он рассчитан на динамический полиморфизм в ООП. Меж тем бывает статический полиморфизм в функциональном стиле. Он не менее мощен и позволяет решать ряд задач существенно проще чем в ОО-стиле.
VD>>Функции могут иметь высший приоритет, в некоторых стратегиях, а данные быть вторичными. IB>И что? Данные-то тут причем...
При том, что для фукнций данные не более чем то чеми они оперируют. Как int или double.
В общем, этот принцип применим к узкому подтипу полиморфизма. И при попытке тарктовать его более широко (без соотвествующих ограничений) становится бессмысленным и даже вредным.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Неправильно выразился... LSP — это только критерий, которому должны удовлетворять подтипы, если мы хотим, чтобы название "подтип" было корректным. Но при этом возможна забавная коллизия, когда с точки зрения компилятора типы находятся в отношении "супертип-подтип", а с точки зрения LSP — нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
IB>>Об этом и речь. Если код завязан на конкретную реализацию не оговоренную в контракте, то код спроектирован не разумно.
VD>Контракты и интерефейсы тоже догмы той идиологии которую ты считашь единственно верной. Меж тем есть другие которые во многих случаях могут оказаться быолее эффективными.
Не могу не согласиться с данным утверждением. В качестве примера можно упомянуть излишнюю многословность контрактов и их, мягко говоря, негибкость при дальнейшем развитии системы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
IB>>>Об этом и речь. Если код завязан на конкретную реализацию не оговоренную в контракте, то код спроектирован не разумно.
VD>>Контракты и интерефейсы тоже догмы той идиологии которую ты считашь единственно верной. Меж тем есть другие которые во многих случаях могут оказаться быолее эффективными.
IT>Не могу не согласиться с данным утверждением. В качестве примера можно упомянуть излишнюю многословность контрактов и их, мягко говоря, негибкость при дальнейшем развитии системы.
А можно по-подробнее о каких альтернативах идёт речь?
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
