OOD fp CS citeseerx.ist.psu.edu — Subclassing errors, OOP, and practically checkable rules to prevent them

OOD programming phppatterns.com — Design Patterns Berserk: Hello World на PHP 5 с использованием паттернов MVC, Observer, Strategy, Decorator, Factory Method и Facade

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

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

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

OOD programming lambda-the-ultimate.org — мифы ООП на LtU

OOD math fp programming 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."

OOD programming bik-top.livejournal.com — исключения: иерархии, misusage и best practices

OOD fp programming dev.by — паттерны проектирования, бессмысленные и беспощадные. "...в языках ML-семейства есть прямое отражение Абстрактной Фабрики. Например, в Haskell, есть конструкция data..."

OOD fp Haskell programming blog.ezyang.com — 23 паттерна банды четырёх в терминах хаскельного ФП, via @Sectoid

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

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

OOD fp CS lambda-the-ultimate.org — Objects to Unify Type Classes and GADTs

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