К своему стыду только недавно узнал про Паттерны проектирования. Сейчас читаю всем известную книгу Эриха Гамма, с соавторами про паттерны. Там в качестве практического примера приводится графический редактор Lexi. По мере прочтения хочется самому закреплять на практике прочитанный материал, применяя паттерны на примере не такого относительно большого примера как Lexi, а чего-то в кодировании поменьше объемом, но со всеми сруктурными особенностями. Может быть что-то связанном с вводом/выводом. Не хочется самому придумывать, навереняка уже есть какие-то уже продуманные задачки.
Спасибо.

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

А>Не хочется самому придумывать, навереняка уже есть какие-то уже продуманные задачки.

Задачка — это когда Вам дают что-то решить, а потом показывают правильное решение и сравнивают его с Вашим, так? Да, интересно было бы заиметь подобный задачник с ответами...

Впрочем, попробуйте решить задачу об агрегировании одних объектов другими. Пусть есть пирамида агрегирования. На вершине этой пирамиды находится самый большой агрегат — фабрика (Factory). Фабрика агрегирует несколько разных объектных сред исполнения (runtime system, Environment). Среда исполнения агрегирует в себе (активные) документы (Document). Документы персистентны. Внутри документа есть всякие предметные области (Domain), которые состоят из компонентов (Component), а те в свою очередь состоят из элементарных объектов (Object).

Factory -<- Environment(s) -<- Document(s) -<- Domain(s) -<- Component(s) -<- Object(s)

1) Придумайте способ как, используя GoF-овские паттерны проектирования, можно запрограммировать такую пирамиду агрегации чтобы эту пирамиду можно было "разбирать" сверху вниз не переписывая при этом код нижестоящих агрегатов.

2) Придумайте способ как запрограммировать пирамиду так чтобы можно было вставлять в нее дополнительные слои не переписывая ни строчки кода. Имеется ввиду следующее
Например, было так:

Document -<- Domain

и мы вставили дополнительный слой System

Document -<- System -<- Domain

и при этом нам не надо переписывать код других слоев.

3) Аналогично пункту (2), придумать способ как так запрограммировать пирамиду агрегации, чтобы ее можно было потом разбирать и сверху и снизу и вставляя слои и убирая лишние.

SYG>

SYG>Factory -<- Environment(s) -<- Document(s) -<- Domain(s) -<- Component(s) -<- Object(s)
SYG>

P. S.
Само-собой, подразумевается, что нижележащим агрегатам нужно уметь получать информацию от вышестоящих (и наоборот). Например, только Фабрика умеет создавать объекты. Только Среда исполнения имеет Журнал работы (StdLog), в который все нижележащие агрегаты могут писать. То есть потоки информации идут в обе стороны по линии агрегирования как вглубь так и наверх.

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

SYG>Впрочем, попробуйте решить задачу об агрегировании одних объектов другими.

SYG>Пусть есть пирамида агрегирования.
Ух, какое название

SYG>На вершине этой пирамиды находится самый большой агрегат — фабрика (Factory).
А разве фабрика должна что-то агрегировать? Ее единственная задача — это скрыть способ создания экземпляров. Разве не так?

SYG>>Пусть есть пирамида агрегирования.
У предложенной вами задачки решение написано прямо в книге. Т.е. используем паттерн Compose.
Все объекты между Factory и Object — есть суть один объект Composite, который содержит ссулки на родителя и потомков. Родители и потомки могут быть также составными. Т.е можно вводить любое кол-во доп. уровней без перепроектирования приложения.
Прийдется видать что-то придумывать себе самому.

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

SYG>>>Пусть есть пирамида агрегирования.
А>У предложенной вами задачки решение написано прямо в книге. Т.е. используем паттерн Compose.
А>Все объекты между Factory и Object — есть суть один объект Composite, который содержит ссулки на родителя и потомков. Родители и потомки могут быть также составными. Т.е можно вводить любое кол-во доп. уровней без перепроектирования приложения.
А>Прийдется видать что-то придумывать себе самому.

Все не так просто! Я бы не стал предлагать Вам задачку решаемую с помощью одного всем известного паттерна. Естественно, агрегат есть composite, но как Вы собираетесь эту систему заставить работать? Как передавать информацию вниз и вверх по уровням агрегации? Как агрегат должен вызывать методы у своих компонентов, а у компонентов компонентов и т.д. вниз по уровням агрегации? А как компоненты будут вызывать методы своего агрегата, агрегата-агрегата и т.д. вверх по уровням агрегации?

Тупой ответ может быть таким:
1) Вниз по уровням агрегации:

Node.View.Location.SetPosition(X, Y);

2) Вверх по уровням агрегации:

node := SELF.Domain.Document.Environment.Factory.NewNode();

Но такое решение жестко фиксирует всю архитектуру приложения. Мы не можем разобрать такую пирамиду агрегации ни сверху, ни, тем более, снизу. Мы не можем вставить дополнительные слои и не можем вынуть существующие слои агрегации. К примеру

Было:

Node.View.Location.SetPosition(X, Y);

Хотим вставить между View и Location дополнительный слой агрегации Graphic2D, тогда все строчки кода подобные вышеприведенной придется переписать на новые:

Node.View.Graphic2D.Location.SetPosition(X, Y);

Или так:
Было

node := SELF.Domain.Document.Environment.Factory.NewNode();

Между Environment и Factory появился новый слой агрегации System, тогда все строчки кода подобные вышеприведенной придется переписать на новые:

node := SELF.Domain.Document.Environment.System.Factory.NewNode();

Вопрос в том как реализовать агрегацию (composite) так чтобы потом ее можно было по всякому разбирать и собирать добавляя или удаляя уровни агрегации не переписывая при этом код.

Здравствуйте, prVovik, Вы писали:

SYG>>На вершине этой пирамиды находится самый большой агрегат — фабрика (Factory).
V>А разве фабрика должна что-то агрегировать? Ее единственная задача — это скрыть способ создания экземпляров. Разве не так?

Правильно, все так! Но кто создаст экземпляр самой фабрики? Другая фабрика? А другую фабрику? Экземпляр самой фабрики должен создать тот кто находится вне ее компетенции. Для всей пирамиды агрегации фабрика является внешним объектом. Но так как агрегат может получить доступ к чему либо тому что сам не имеет только попросив об этом свой непосредственный (вышестоящий) агрегат, то отсюда вытекает, то что фабрика должна располагаться в вершине агрегации.


Например, в приложении Windows

MainForm--<--Factory(es)--<--Environment(s)--<--(Всё-Всё-Всё)

Можно считать, что главная форма приложения Windows создается автоматически. И она (главная форма приложения) создает Фабрику, поскольку только она знает как ее создать.

Ух ты!!! Я тоже только недавно приобщился к паттернам текущий проект просто по швам затрещал от переделок.

Я бы в текущей задаче встроил систему команд или сообщений.

С уважением.

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

А>К своему стыду только недавно узнал про Паттерны проектирования. Сейчас читаю всем известную книгу Эриха Гамма, с соавторами про паттерны. Там в качестве практического примера приводится графический редактор Lexi. По мере прочтения хочется самому закреплять на практике прочитанный материал, применяя паттерны на примере не такого относительно большого примера как Lexi, а чего-то в кодировании поменьше объемом, но со всеми сруктурными особенностями. Может быть что-то связанном с вводом/выводом. Не хочется самому придумывать, навереняка уже есть какие-то уже продуманные задачки.
Нету пока нигде ни фига. Мы тут с пацанами начинаем придумывать сборник задач по ООП, где задачи на паттерны будут. А пока — только самому изощряться.

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

SYG>Здравствуйте, prVovik, Вы писали:

SYG>>>На вершине этой пирамиды находится самый большой агрегат — фабрика (Factory).
V>>А разве фабрика должна что-то агрегировать? Ее единственная задача — это скрыть способ создания экземпляров. Разве не так?

SYG>Правильно, все так! Но кто создаст экземпляр самой фабрики?
Обычно фабрика — это синглтон.

Здравствуйте, prVovik, Вы писали:

SYG>>Правильно, все так! Но кто создаст экземпляр самой фабрики?
V>Обычно фабрика — это синглтон.

Если фабрика синглетон, значит, тем более, она обязана быть в вершине агрегации. В самом деле, не может же какой-либо динамический объект агрегировать (статический) синглетон. Динамический объект может быть осведомлен о синглетоне, но агрегировать его (владеть им) он не может (время жизни синглетона больше времени жизни динамических объектов).

А вообще, синглетоны вредны тем что жестко фиксируют архитектуру программы. Лучше обходится без них. Вернее, обходится минимально возможным их количеством = 1 сама программа.

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

SYG>Тупой ответ может быть таким:
SYG>1) Вниз по уровням агрегации:
SYG>

SYG>Node.View.Location.SetPosition(X, Y);
SYG>

SYG>2) Вверх по уровням агрегации:
SYG>

SYG>node := SELF.Domain.Document.Environment.Factory.NewNode();
SYG>

SYG>Но такое решение жестко фиксирует всю архитектуру приложения. Мы не можем разобрать такую пирамиду агрегации ни сверху, ни, тем более, снизу. Мы не можем вставить дополнительные слои и не можем вынуть существующие слои агрегации.

В книге рекомендут использовать паттерн Command.

К примеру

SYG>Было:
SYG>

SYG>Node.View.Location.SetPosition(X, Y);
SYG>

SYG>Хотим вставить между View и Location дополнительный слой агрегации Graphic2D, тогда все строчки кода подобные вышеприведенной придется переписать на новые:
SYG>

SYG>Node.View.Graphic2D.Location.SetPosition(X, Y);
SYG>

Здесь все зависит от конкретной задачи. Мне не очень понятно, что именно нужно. В примере Lexi для добавления ф-ти использовали Decore и Bridge.

SYG>Вопрос в том как реализовать агрегацию (composite) так чтобы потом ее можно было по всякому разбирать и собирать добавляя или удаляя уровни агрегации не переписывая при этом код.
Так весь смысл Composite, что-бы в коде писать Composite.Draw() или другой метод. А сама реализация уже в классе. Добавления еще одного объекта или дополнительной агрегации кода приложения не меняет.

Здравствуйте, LaptevVV, Вы писали:

LVV>Нету пока нигде ни фига. Мы тут с пацанами начинаем придумывать сборник задач по ООП, где задачи на паттерны будут. А пока — только самому изощряться.

К вам будет можно присоединиться?
Мне, в принципе, тоже хотелось бы создать GuideLine по этой тематике с помощью набора задач.

"Т.е. ты прочитал? Ну давай, здесь как? А если чуть посложнее, а если несколько, и вот тебе задача на страндартную ошибку проектирования, справился? Нет, тогда вот тебе четкая линка — читай то и то, потом выполнишь контр. задания и пойдем дальше."

Здравствуйте, flax, Вы писали:

F>К вам будет можно присоединиться?
F>Мне, в принципе, тоже хотелось бы создать GuideLine по этой тематике с помощью набора задач.

F>"Т.е. ты прочитал? Ну давай, здесь как? А если чуть посложнее, а если несколько, и вот тебе задача на страндартную ошибку проектирования, справился? Нет, тогда вот тебе четкая линка — читай то и то, потом выполнишь контр. задания и пойдем дальше."

Тогда надо начинать с заданий на простые структурные паттерны типа Adapter, Singleton.
MonoState, Bridge. Потом переходить к простым паттернам поведениявроде итератор, команда, интерпретатор, визитер. Паттерны порождающие оставить на конец.

Беда в том, что для реализации этих заданий нужна задача типа этюда по программированию (Уэзерелл), или курсовой работы. Такие объемные задачи нелегко придумать ( а уж студентам и подавно сложно их делать в качестве упражнения) для некоторых сложных паттернов. С простыми все вроде проще: паттерн команда, как в у банды четырех, привязывается к реализации меню, например. Singleton — единственность приложения.

И еще одна проблема: польза паттернов четко осознается при сопровождении-рефакторинге, когда надо добавлять функциональность или изменять существующую. Получается, что задание должно состоять из 2 частей: сначала написать без использования паттернов, а потом переписать то же самое с паттернами.

Здравствуйте, LaptevVV, Вы писали:

LVV>Нету пока нигде ни фига. Мы тут с пацанами начинаем придумывать сборник задач по ООП, где задачи на паттерны будут.
Есть довольное большое число вопросов в разных примерах сертификационных экзаменов Sun, IBM.
Например http://groups.yahoo.com/group/scea_j2ee/files/ (требует регистрации на яхе), файл SCEA Practice Questions.zip .
Бывают вопросы разной сложности, на задачи не тянут а на задачки — вполне

Всего хорошего.
Виктор.

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

SYG>Если фабрика синглетон, значит, тем более, она обязана быть в вершине агрегации.
Зачем?

SYG>В самом деле, не может же какой-либо динамический объект агрегировать (статический) синглетон. Динамический объект может быть осведомлен о синглетоне, но агрегировать его (владеть им) он не может (время жизни синглетона больше времени жизни динамических объектов).
А почему кто-то кого-то обязательно должен агрегировать?

SYG>А вообще, синглетоны вредны тем что жестко фиксируют архитектуру программы. Лучше обходится без них. Вернее, обходится минимально возможным их количеством = 1 сама программа.
А я считаю, что не надо придумывать никаких рамок. Если суть объекта предполагает уникальность, то почему бы не зафиксировать это явно, сделав его синглтоном? А может быть вы считаете, что паттерн "синглтон" предполагает уникальность объекта во вселенной? Нет, это не так. Он уникален лишь по отношению к некоторой абстракции: к программе, к подсистеме и пр.

Здравствуйте, prVovik, Вы писали:

V>А почему кто-то кого-то обязательно должен агрегировать?

Справедливый вопрос. Ответ на него я не знаю. Но так получилось, что все окружающие нас предметы являются агрегатами. Агрегат — значит состоит из чего-то более мелкого. Причем количество типов более мелких агрегатов меньше чем количество типов более крупных агрегатов. Вот например несколько сотен типов атомов таблицы Менделеева состоят всего из трех типов "элементарных" частиц электрон+протон+нейтрон. Бесчисленное количество типов молекул состоит из нескольких сотен типов атомов. "Бесчисленное" количество типов живых существ состоят всего из нескольких типов аминокислот (или чего там еще — я не спец в этом вопросе). Все предметы которые мы видим вокруг себя состоят из чего-то. Еще пример: Слово — агрегат букв. Букв в алфавите мало, а слов построеных из этих букв много. Агрегаты повсюду, а элементарных объектов очень мало. Традиционное ООП дает нам возможность строить элементарные объекты. То что в будущем придет на смену классического ООП даст нам возможность с легкостью работать с агрегатами абстрагируясь от конкретных механизмов агрегации.

V>А я считаю, что не надо придумывать никаких рамок. Если суть объекта предполагает уникальность, то почему бы не зафиксировать это явно, сделав его синглтоном? А может быть вы считаете, что паттерн "синглтон" предполагает уникальность объекта во вселенной? Нет, это не так. Он уникален лишь по отношению к некоторой абстракции: к программе, к подсистеме и пр.

А я разьве придумываю рамки? Раз он уникален только по отношению к некой подсистеме, это и означает, что эта самая подсистема агрегирует (содержит) один экземпляр этого объекта. А сама эта подсистема агрегируется какой-то более крупной системой.

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

А>В книге рекомендут использовать паттерн Command.

1) Но у классического паттерна Command нет параметров вызова. То есть, как передать X,Y в метод SetPosition(X, Y)?

2) А как получить сам объект Command минуя несколько уровней агрегации?

3) Если использовать механизм сообщений (там можно будет параметры передавать), то скорость работы упадет. Хотелось бы эффективностью не жертвовать...

4) А еще хотелось бы кода поменьше писать для поддержки этого механизма.


А>Так весь смысл Composite, что-бы в коде писать Composite.Draw() или другой метод. А сама реализация уже в классе. Добавления еще одного объекта или дополнительной агрегации кода приложения не меняет.

Но ведь на разных уровнях агрегации (в подавляющем большинстве случаев, короче — всегда) находятся объекты разных типов. То есть у них нет общих методов, типа Draw() или ему подобных. Наверняка присутствующий у всех метод это метод SetAggregate(NewAggregate)...

А>>Так весь смысл Composite, что-бы в коде писать Composite.Draw() или другой метод. А сама реализация уже в классе. Добавления еще одного объекта или дополнительной агрегации кода приложения не меняет.

SYG>Но ведь на разных уровнях агрегации (в подавляющем большинстве случаев, короче — всегда) находятся объекты разных типов. То есть у них нет общих методов, типа Draw() или ему подобных. Наверняка присутствующий у всех метод это метод SetAggregate(NewAggregate)...

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

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


SYG>Справедливый вопрос. Ответ на него я не знаю. Но так получилось, что все окружающие нас предметы являются агрегатами. Агрегат — значит состоит из чего-то более мелкого. Причем количество типов более мелких агрегатов меньше чем количество типов более крупных агрегатов. Вот например несколько сотен типов атомов таблицы Менделеева состоят всего из трех типов "элементарных" частиц электрон+протон+нейтрон. Бесчисленное количество типов молекул состоит из нескольких сотен типов атомов. "Бесчисленное" количество типов живых существ состоят всего из нескольких типов аминокислот (или чего там еще — я не спец в этом вопросе). Все предметы которые мы видим вокруг себя состоят из чего-то. Еще пример: Слово — агрегат букв. Букв в алфавите мало, а слов построеных из этих букв много. Агрегаты повсюду, а элементарных объектов очень мало. Традиционное ООП дает нам возможность строить элементарные объекты. То что в будущем придет на смену классического ООП даст нам возможность с легкостью работать с агрегатами абстрагируясь от конкретных механизмов агрегации.
Вопрос не в этом. Почему вы считаете, что либо фабрика должна агрегировать создаваемые ею объекты, либо объекты должны агрегировать фабрику, которая их создала. Помоему, это, мягко говоря, странно

SYG>Раз он уникален только по отношению к некой подсистеме, это и означает, что эта самая подсистема агрегирует (содержит) один экземпляр этого объекта.
Не обязательно. Объект, в принцепе, может передаваться системе из вне.