Илья Ермаков писал(а):
Дело в том, что все эти расширенные ОО-кунштюки, про которые упоминает Мейер, можно трактовать просто как паттерны, имея самые базовые механизмы ООП и имитируя что угодно композицией.
...
Как я понял, Мейеру как раз паттерны не нравятся (из-за "размножения маленьких классов") и он вводит другой механизм (делегатов, типа).
Меня больше заинтересовали рассуждения о важности проработки состава и связей объектов на предмет распределения свойств. В принципе, когда рассматривал область с подстановками в
этом примере - обнаружил, что это удобно и в смысле такого вот обобщения свойств. Правда, цели показать "классообразование" я не ставил, поэтому не развивал это в примере. В то же время вот это:
...
Чем ниже компонент уровнем в технической системе, тем более "тупым" он должен быть. Он должен выполнять одновариантную максимально ненастраиваемую работу. Принятие решений должно происходить на верхних уровнях. Принятие решений концентрируется на верхнем уровне, "тупая" обработка - на нижних.
Как следствие - компоненты должны быть как можно менее параметризуемыми. Если "напрашивается" параметризуемый компонент, его надо разбивать на части, чтобы вместо настройки сложного компонента надсистема просто выполняла выбор того или иного простого компонента.
...
в принципе вроде как отрицает подобные обобщения (ради построения программных сущностей, "собирающих с миру по нитке" среди иерархии классов нечто, способное выполнить работу, запрашиваемую изначальным вызовом, прежде чем собственно поработать). Или это не так надо понимать?