Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Аноним, Вы писали:

А>>Если вы все-таки возьмете эту книгу, то в паттерне Compose, все объекты прикладные объекты, в т.ч и агрегирующий объект наследуются от одного абстарктного объекта-интерфеса. Работа со всей системой ведется только через эти интерфейсы. А сами объекты, получая например вызов draw() с верхнего уровня, уже сами разбираются как себя рисовать в зависимости от его природы.

SYG>А что Вы, собственно, привязались к паттерну Compose? Агрегат, в общем случае, не описывается одним лишь только этим паттерном. Это хорошо когда у всех компонентов агрегата на любой глубине агрегации есть метод draw(); а если нет? Вот, например, автомобиль — это агрегат. У автомобильного мотора есть метод Run(); но ни у какого другого компонента этого метода больше нет. И что тогда делать? Паттерн Compose тут недостаточен. Я же Вам говорю, что все компоненты агрегата, в подавляющем большинстве случаев, есть объекты совсем разных типов, то есть общих методов у них ничтожно малое количество.

Кажется, механизм, примерно удовлетворяющий Вашим требованиям (имеется в виду хождение по иерархии), реализован в библиотеке Stingray Foundation Library. Подробности, к сожалению, уже не помню (но если интересно могу уточнить).Кажется, у Stingray этот механизм, кроме всего прочего, используется совместно с паттерном MVC (который, есть классический пример Composite )