← All posts tagged OOD

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

вопрос, спровоцированный собеседованием в соседней комнате: если взять за основу C++ и набор паттернов GoF, как может выглядеть ответ на вопрос "каким образом нужно изменить семантику языка, чтобы в данном паттерне (как отдельной архитектурной единице) пропала необходимость"? так, например, паттерн Strategy не имеет ценности в языке с поддежкой HOF — а Visitor заменяется паттерн-матчингом по ADT. приглашаю к обсуждению

а существуют ли ОО-языки, в которых не было бы наследования как такового, но явно присутствовали бы отношения реализуется посредством (композиция, приватное наследование в C++), является (наследование интерфейса), и диспетчеризуется по (ad-hoc полиморфизм, явно выделяется паттерном NVI)?

akuklev.livejournal.com — занятный, хотя и местами спорный текст о некоторых недостатках ООП (без множественной диспетчеризации):

"a + b + c — это вовсе не a.add(b).add(c)
a + b + c = (AdditiveSemigroup.[+] a, b, c)

А вот функция AdditiveSemigroup.[+] должна извлекать наиближайшего общего предка a, b и c, являющгося имплементирующим интерфейс AdditiveSemigroup, в котором должна иметься статическая функция add(a, b), выполняющая аксиомы полугруппы. И вот этот AdditiveSemigroup.[+] должен вызывать эту функцию для сложения. Причём, оптимизируя вызовы для параллелизации, т.е. превращая список в бинарное дерева и редуцируя его. Не (((a + b) + c) + d), а ((a + b) + (c + d)).
А ежели аддитивная семигруппа ещё явлется и моноидом, то AdditiveSemigroup.[+]() должна выплёвывать .unit."

RAII, очевидно, влечёт за собой неидемпотентность конструтора и деструктора объекта; впрочем, единственный язык, в котором я встречал явный квалификатор идемпотентности метода — Slice, язык интерфейсов ZeroC ICE. с учётом того, что free lunch is over, это несколько странно

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

лучшее лекарство от нарушений принципа подстановки Лисков — в понимании того, что статические типы описывают статические же инварианты; для работы в динамике они не подходят