GrandM-Patterns_in_Java
.pdf
1 26 |
• Глава 5. Парождающие шаблоны проектирования |
|
Рассмотрим эти роли.и Т.Д. j
WidgetAlF, WidgetBIF Интерфейсы, выступаюшие в этой роли, соответст. вуют сервису или характеристике продукта. Классы, которые реализуют один из этих интерфейсов, работают с сервисом или характеристикой, которой соот. ветствует интерфейс.
Ввиду нехватки места здесь показаны только два таких интерфейса. Большая часть приложений с шаблоном Abstract Factory имеет более двух интерфейсовот подобного рода. Интерфейсов должно быть столько, сколько используется дельных характеристик и сервисовипроТ.д.укта.
ProductlWidgetA, Product2WidgetA Классы, выступающие в этой роли,
соответствуют конкретной характеристике определенного продукта. В общем, можно ссылаться на классы, играющие эти роли, как на конкретные элементы окна.
Client. Классы в роли C l ient используют конкретные классы элементов окна, чтобы запросить или получить сервис от того продукта, с которым работает клиент. Клиентские классы взаимодействуют с конкретными классами элемен тов окон только через интерфейс WidgetIF. Они не зависят от реальных кон кретных классов элементов окон, с которыми работаютдля.
FactoryIF. Интерфейсы в этой роли объявляют методы создания экземпляров конкретных классов элементов окон. Каждый такой метод возвращает экземп ляр класса, который реализует свой интерфейс Widge t I F. Классы, отвечающие за создание конкретных объектов элементов окон, реализуют интерфейс, вы ступающий в этой роли. и Т.Д.
ConcreteFactoryl,дляConcreteFactory2 Классы в этой роли реализуют интер
фейс FactoryIF создания экземпляров конкретных классов элементов окон. Каждый класс, выступающий в этой роли, соответствует отдельному продукту,
с которым может работать класс Client. Каждый метод класса ConcreteFactory
создает конкретный элемент окна определенного вида. Однакодлявсе конкретнытем элементы окна, создаваемые этими методами, предназначены работы с продуктом, которому соответствует класс ConcreteFactory.
Клиентские классы, вызывающие эти методы, не должны иметь никакой непО средственной информации об этих конкретных классах-фабриках. Вместо этоro онидолжны обращаться к экземплярам этих классов через интерфейс Factorylf.
РЕАЛИЗАЦИЯ
Основной задачей, решаемой при реализации шаблона Abstract Factory, явлЯ- !
ется проблема написания механизма, который используется клиентскимJI
классами для создания и доступа к объектам FactoryIF. Самая простая ситуа ция возникает тогда, когда клиентские объекты должны работать только с од ним продуктом на протяжении всего периода функционирования программызэ.
В этом случае некоторые классы обычно имеют статические переменные,
данные для класса ConcreteFactory, используемого на стадии выполненttl1
Abstгact Factory - 127
программы. Переменная может быть открытой, или ее значение может быть получено через открытый статический метод.
Если абстрактный объект-фабрика будет использовать информацию, предос тавляемую выдающим запрос клиентом, для выбора одного из нескольких кон кретных объектов-фабрик, то можно использовать шаблон Factory Method.
СЛЕДСТВИЯ
©Клиентские классы не зависят от конкретных классов элементов окон, ко торые они используют.
©Добавление (в отличие от написания) классов для работы с дополнительны
ми продуктами осуществляется просто. Обычно на класс конкретного объекта-фабрики ссылка должна делаться только в одном месте. Кроме того, несложно заменить конкретный объект-фабрику, используемый для работы с определенным продуктом.
©Заставляя клиентские классы проходить через интерфейс FactoryIF с це
лью создания конкретных объектов элементов окон, шаблон Abstract Factory гарантируетдля , что клиентские объекты используют соответствующий набор объектов работы с продуктом.
@) Главный недостаток шаблона Abstract Factory в том, что при взаимодейст вии с продуктом может понадобиться большая работа по написанию нового набора классов. Значительных усилий требует также расширение набора ха рактеристик, которые существующий набор классов способен реализовать. Если должен поддерживаться новый продукт, пишется полный набор кон кретных классов элементов окон с целью поддержкидляэтого продукта. Необ ходимо написать конкретный класс элемента окна каждого интерфейса
Widge tI F. Если имеется множество интерфейсов WidgetIF, то для под
держки дополнительного продукта потребуется большая работа.
Добавление доступа к дополнительной характеристике взаимодействующих продуктов тоже может потребовать значительных усилий, если существует много поддерживаемых продуктов. При этом пишется новый интерфейс WidgetIF, соответствующий новой характеристике, и новый конкретный класс элемента окна, соответствующий каждому продукту.
€) Клиентские объекты могут потребовать, чтобы классы элементов управле ния окна бьuIИ организованы в виде иерархии, которая обслуживает потреб
ности клиентских объектов. Шаблон Abstract Factory сам по себе не подхо дит для решения этой задачи, так как он требует организации конкретных классов элементов окон в виде иерархии классов, не зависящей от клиент ских объектов. Это препятствие может быть преодолено посредством объе динения шаблона Bridge с шаблоном Abstract Factory:
1 . |
Создайте иерархию не зависящих от продуктов |
классов элементов |
|
окон, удовлетворяющих требованиям клиентских |
классов. При этом |
|
каждый не зависящий от продукта класс элемента окна делегирует |
|
128 |
• Глава 5. Порождающие шаблоны проектирования |
|
зависящую от продукта логику зависящему от продукта классу, кото
ааует. а интерфейс WidgetI F.
2.Пакет j v wt содержит классы, реализующие использование такого
варианта. Классы, подобные Button и TextField, содержат логикуЭЛI, которая не зависит от используемой системы управления окнами. классы обеспечивают естественный внешний вид и стиль посредством делегирования операций системы управления окнами конкретным клас
сам элементов окон , реализующим интерфейсы, определенные в пакете j ava . awt . peer.
ПРИМЕНЕНИЕ В JAVA API
Шаблон Abstract Factory используется в Java API с целью реализации класса j ava . awt . Tool k i t. Это класс абстрактной фабрики , применяемый для созда ния объектов, работающих с «родной.) системой управления окнами. Используе мый класс конкретной фабрики задается кодом инициализации, и единственный объект конкретной фабрики возвращается его методом getDe faultTool kit.
ПРИМЕР КОДА
Чтобы рассмотреть пример кода этого шаблона, вернемся к проблеме, описан ной в разделе «KoHTeKCTh. На рис. 5.8 представлена расширенная диаrpамма классов, в которой содержится шаблон Abstract Factory.
Экземпляр класса C l ient управляет процессом удаленной диагностики. После определения архитектуры машины он должен диагностировать ее. Он передает тип архитектуры методу createTool ki t объекта Too l kitFactory. Этот метод возвращает экземпляр класса, например, EmberToolkit1 или Enginol aTool kit, который реализует интерфейс Archi tectureTool ki t F для заданной архитек туры компьютера. Затем объект C lient может использовать объект Archi tectureToo lki t I F для создания объектов, которые моделируют CPU (Centra\ Processing Units, центральные процессорные устройства), MMU (Мето!)' Management Units, блоки управления памятью) и другие компоненты соответ ствующей архитектуры.
Приведем код, который реализует проект диагностики удаленного компьютера, изображенный на рис. 5.8. Абстрактные классы элементов окна имеют очевиД ную структуру.
Код для конкретного класса-фабрики, который создает экземпляры классоВ
для тестирования компьютеров, имеющих архитектуру Ember, выглядит сле дующим образом:
class EmberToolkit implernents ArchitectureToolkitIF{ public CPU createCPU () (
return new EmberCPU ( ) ;
АО тг ст ГОСlurу - " T
} / / createCPU ( )
public ммu createММ()U (
return пеи EmberМ М U ( );
// с rеаtеММU ( )
// class EmberFactory
Создает ДЛЯ него объекты ArchitectureToolkitIF
---.L
г- ToolkitFactory createToolkit(architecture) : ArchitectureToolkitIF
|
|
|
|
|
|
«interface» |
|
|
|
|
ArchitectureToolkitIF |
|
|
|
|
createCPU |
|
|
|
|
createMMU |
|
|
|
|
... |
|
|
|
|
|
|
|
|
|
* |
|
|
|
|
II |
|
|
|
|
II |
|
|
|
|
I |
|
|
|
|
I |
|
|
|
|
I |
|
|
|
|
- I - - - - - - - - - - - - - - - - - - , |
|||
|
I |
|
I |
|
|
I |
|
I |
|
|
I |
|
I |
|
|
I |
|
I |
|
|
I |
|
I |
|
|
EmberToolkit |
|
1 |
II |
createCPU |
|
II |
||
|
|
I |
||
createMMU |
|
|
EnginolaToolkit |
|
... |
1 |
|
|
createCPU |
|
|
|||
|
|
|
|
createMMU |
|
... |
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
Использует |
|
|
|
|
I |
|
Client |
1] |
||||
|
|
|
|
|
|
|
|
|
|
|
I |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Создает |
'" |
|
I |
«interface» |
I * |
|
|
|
|||||||
|
|
... |
|
|
|
||||||||||
|
|
|
|
|
* |
I |
|
|
|
|
|||||
|
|
|
|
|
|
|
CPU |
|
|
|
|
Использует |
|
||
|
|
|
|
I- - - - - - - - IL - - - - - - - 1 |
|
||||||||||
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
I |
|
|
|
I |
|
|
|
|
|||
|
|
|
|
EmberCPU |
I |
I EnginoIlaCPU |
I |
|
|||||||
ет |
|
|
|
||||||||||||
Созда] |
|
|
|
i * |
|
|
* |
|
|
|
|
|
|||
|
|
...... |
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
Создает...... |
|
|
|
|
||||
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. . . |
1 |
|
|
|
«interface» L |
|
Исполь)ует |
|||
|
|
|
|
I |
|
|
|
|
* |
... |
|
|
"'Создает |
|
|
MMU |
J |
|
|
||
|
|
|
|
|
|
* |
|
|
|
|
|
|
|
- - - - - - - -IL -- - - - - - 1 |
|
||||||
|
|
|
I |
|
|
|
|
|
I |
|
|
|
* |
I |
|
|
|
|
|
I |
|
|
|
EnginolaMMU I |
I |
EmberMMU I |
||||||
|
|
|||||||||
Создает |
|
|
i *
Рис. 5.8. Классы диагностики вместе с абстрактной фабрикой
130 • Глава 5. Порождающие шаблоны проектирования
Код для интерфейса фабрики:
pub1ic interface ArchitectureToo1kitIF pub1ic abstract ммСРОu createCPO () pub1ic abstract createММ()U ;
// Abs t ractFactory
вэтой реализации шаблона Abstract Factory для создания объектов Archi tectureToo l ki t I F используется шаблон Factory Method. В нижеприведенном
листинге класс-фабрика отвечает за создание объектов ArchitectureTool kitIF .
pub1ic с1азз Too1kitFactory 
/* *
* Единственный экземпляр этого класса .
* /
=private static Too1kitFactory mylnstance new Too1kitFactory () ;
/ / Символические имена для идентификации архитектур компьютеров . |
||||
pub1ic fina1 |
static |
int ENGIHOLA |
= |
900 ; |
pub1ic fina1 |
static |
int EМВER |
= |
901 ; |
/ / . . .
pub1ic static Too1kitFactory getlnstance () { return mylnstance ;
/ / ge tInstance ( )
/* *
* Возвращает вновь созданный объект, который реализует
интерфейс .
*ArchitectureToolkitIF для данной архитектуры компьютера .
*/
pub1ic
ArchitectureToo1kitIF createToo1kit (int architecture) { switch (architecture) {
case ENGINOLA:
return new Engino1aToo1kit () ;
case EМВER:
return new EmberToolkit ( ) ;
|
Abstroct Foctory • 131 |
} / / switch |
= Integer . toString (arehiteeture) ; |
String errМsg |
throw new IllegalArgumentExeeption (errMsg) ;
// createToo l ki t ( int )
// c lass Toolki tFactory
Клиентские классы обычно создают объекты конкретных элементов управле ния окна, используя для этой цели код, который выглядит примерно так:
publie elass Client (
publie void doIt ()
ToolkitFaetory= rnyFaetory;
rnyFaetory ToolkitFaetory. getInstanee () ; ArehiteetureToolkitIF= af ;
сриaf ериrnyFaetory= . ereateToolkit (ToolkitFaetory . EМВER) ; af . ereateCPU ( ) ;
// doI t
// class Cl ient
ШАБЛОНЫ ПРОЕКТИРОВАНИЯ,
СВЯЗАННЫЕ С ШАБЛОНОМ ABSTRACT FACTORY
Factory Method. В последнем примере абстрактный класс-фабрика использует рикушаблон Factory Method для принятия решения, какой конкретный объект-фаб
передать клиентскому классу.
Singleton. Конкретные классы-фабрики обычно реализуются как классы
Singleton.
Этот шаблон ранее был описан в работе [GoF95].
СИНОПСИС .3Щ1.а<>а'll
Шаблон Builder позволяет объекту клиента создавать сложный объект, дJ1Я него только тип и содержимое. Клиент избавлен от информации о построения объекта.
КОНТЕКСТ
Рассмотрим написание программы шлюза электронной почты. Программа поих
лучает сообшения электронной почты в формате MIME1• Она отправляет
вдругом формате, соответствуюшем другому виду системы электронной почты.
Эта проблема хорошо решается с помошью шаблона Builder. Очень просто соз]
дать программу, используюшую объект, который занимается синтаксическимВQ
анализом сообщений в формате MIME. КаЖдое анализируемое сообщение
время синтаксического анализа образует пару вместе с объектом-строителем
используемым синтаксическим анализатором дJ1я создания сообщения в HOBO
формате. Как только синтаксический анализатор распознает какой-либо заro
ловок и тело сообщения, он вызывает соответствующий метод объекта-строи'; |
|
теля, с которым работает. |
j |
|
|
На рис. 5.9 изображена диаграмма классов, описывающая такую структуру.
Класс Mes sageManager отвечает за сбор сообщений электронной почты в фо .
мате MIME и активизацию их передачи. Сообщения, которыми он непосред
венно управляет, являются экземплярами класса MIMEMsg.
Экземпляры класса MIMEMsg инкапсулируют сообщения электронной поч
в формате MIME. Если объект Mes sageManager хочет передать сообщениI |
|
в формате, отличном от MIME, то он должен заново создать сообщение в нуж! |
|
ном формате. Содержание нового сообщения должно быть таким же, как и col |
|
держание сообщения в МIМЕ-формате, или настолько близким, насколько пOJij |
|
|
|
зволяет новый формат. |
I |
Класс MIMEParser представляет собой подкласс класса MessageParser, KOТOJ |
|
рый может выполнять синтаксический анализ сообщений электронной почт. |
|||
в формате MIME и передавать их содержание объекту-строителю. |
1 |
||
|
|
|
.. |
|
|
|
j |
I MIME |
это аббревиа1)'ра словосочетания Multipurpose Intemet Mail Extensions |
||
целевы_ |
|
о стандарт, которому подчин |
|
е раСШИРСI IИЯ интеРl lетпочты), определяющег |
|
||
ются почти все сообщения электронной почты Иllтернета. Описание M I M E МОЖJl |
|||
найти по адресу http://mgrang.homc.mindspring.com/mime.html. |
(MIIO . |
||
|
|
MessageManager 1 . |
|
|
|
|
Управляет |
|
|
0...J1 |
MIMEMgg |
д |
|
т |
|
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* |
|
|
|
|
|
|||
r |
1 |
отправитель |
I |
1 |
|
|
|
Подвергается синтаксическому ... |
|
|
|
|
|
|
|
|||||||||||||
|
|
|
разбора |
|||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0 |
. . |
|
пре |
|
ме |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
синтаксическоrо |
||||||||
|
|
... Отправляет |
|
|
|
|
|
|
раэбору |
|
|
|
|
|
|
1 |
синтаксический |
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
анализатор |
|||||||||||||
|
|
0 |
|
* |
|
«interface» |
|
|
|
|
|
|
|
MIMEParser |
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||
|
|
|
.. |
|
|
OutboundMessageIF |
|
|
|
|
|
|
parse(msg:MIMEMessage) |
|
||||||||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||||||||||||
|
получатель |
|
|
send() |
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
Направляет ... |
|
|
|
|
|
|
||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
о..* |
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
II |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
I |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I.- _ _ _ _ _ _ - - - - - . J - - - - - - -I1 |
|
|
|
|
|
|
Message8ui/der |
|
|
|
||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
|
|
I |
|
|
|
|
|
|
I |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
II |
|
|
|
|
getInstance(to:String):MessageBuilder |
||||||||||||||
|
|
PROFSMsg |
|
|
|
|
|
|
|
|||||||||||||||||||
r |
|
I |
|
|
II |
|
|
|
|
|||||||||||||||||||
|
|
|
|
|
|
|
I |
|
|
|
|
to(:String) |
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
I |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
1 |
r |
|
III |
|
I |
|
|
from(:Stгing) |
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
oгganization(:Stгing) |
|
|
|
|
|
|
|
|
|||||||||||||
|
|
|
|
|
|
|
|
MAPIMsg |
|
|
p/ainText(:Stгing) |
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
1 |
|
|
... |
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
jpeglmage(:Image). |
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
. . |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Соэдает |
|
|
getOutboundMsg() |
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I |
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
..... |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
1 I1 |
|
I |
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
.....Соэдает |
|
|
|
|
|
|
MAPIBuilder |
|
|
|
1 I1 |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROFSBuilder |
|||||
|
|
|
|
|
|
|
|
Рис. 5.9. |
|
Пример класса-строителя |
|
|
|
|
|
|
|
|
|
|
|
|||||||
MessageBui lder - это абстрактный класс-строитель. Он определяет методы,
соответствующие различным полям заголовков и телам, которые поддержива
ются стандартом MIME. Класс MessageBuilder объявляет абстрактные методы,
которые соответствуют обязательным полям заголовков и наиболее распро
страненным типам сообщения. Он делает эти методы абстрактными, так как
ВСе конкретные подклассы класса MessageBui lder должны определять эти ме тои ды. Однако некоторые необязательные поля заголовков (например, organization)
специфические форматы сообщения (например, Image/ Jpeg) могут не под
держиваться всеми форматами сообщений, поэтому класс Mes s ageBui lder
Предоставляет «бездействующие» реализации таких методов.
Класс Mess ageBu i lde r определяет также статический метод get lnstance,
которому объект MIMEParser передает адрес назначения анализируемого сооб
Щения. По этому адресу метод get lns tance определяет формат сообщения,
134 • Глава 5. Порождающие шаблоны проектирования
необходимый ДЛЯ нового сообщения. Он возвращает экземпляр подкласса класса MessageBui l der, соответствующий формату нового сообщения, в объ ект MIMEParser.
МAPIBuilder и PROFSBuilder - это конкретные классы-строители для созда ния МAPI- и РRОFS-сообщений соответственно.
Классы-строители создают объекты продуктов, которые реализуют интерфейс OutboundMe s sage I F. Этот интерфейс определяет метод send, предназначен ный для отправки сообщений электронной почты по нужному адресу.
На рис. 5. 1О представлена диаграмма взаимодействия, описывающая совмест ную работу этих классов.
|
|
|
l:receive(msg:MIMEMsg) |
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
I |
:MessageManager |
I |
|
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
I |
|
|
|
|
|||||||
|
I |
|
OutboundMessagelF |
1 |
1.2: sendO |
|
|
|
|
|
|
|
|
|
1 |
||||||
|
|
I |
|
|
|
|
|
|
|
1.1:outMsg :- parse(msg:MIMEMsg) |
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
1.1.2: to(:String) |
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
1.1.3: from(:String) |
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
1.1.4: plainText(:String) |
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
1.1.5:jpegImage(:Image) |
|
|
|
|
|
|
|
|
|
|
|
|
||||
I |
builder:MAPIBuiLder I |
1.1.6: outMsg :- getOutboundMsg() |
|
I |
:MIMEParser |
I |
|
||||||||||||||
I |
|
||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
1'.'.""";"''',. ",и."..",(to"tЛ••) |
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
....- |
...L.. --, |
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
I |
MessageBuiLder |
I |
|
|||||
Рис. 5.10. Взаимодействие в шаблоне Builder
Опишем изображенную на рис. 5. 1 0 ситуацию.
1.Объект Mes s ageManager получает сообщение электронной почты.
1.1. Объект MessageManager вызьшает метод parse класса MlМEParser.
Он возвращает объект OutboundMessageIF, который инкапсу
лирует новое сообщение в нужном формате.
1.1.1. Объект MIMEParser вызывает метод get lnstance клас са Mes sageBui l der, передавая ему адрес назначения электронной почты. Анализируя адрес, метод выбирает
конкретный подкласс класса Mes sageBui lder И создает его экземпляр.
|
Builder - 135 |
1.1.2. |
Объект MIMEParser передает адрес назначения элек |
|
тронной почты методу to объекта MessageBuilder. |
1.1.3. |
Объект MIMEParser передает исходящий адрес элек |
|
тронной почты методу from объекта Mes sageBu i lder. |
1.1.4. |
Объект MIMEParser передает содержимое сообщения |
|
электронной почты методу plai nText объекта Mes - |
|
sageBui lder. |
1.1.5. |
Объект MIMEParser передает jреg-изображение, при |
|
соединенное к сообщению электронной почты, методу |
|
j peglmage объекта MessageBuilder. |
1. 1.6. |
Объект MIMEParser вызывает метод getOutboundМsg |
|
объекта MessageBui lder ДЛЯ завершения обработки |
|
старого и считывания нового сообщения. |
1.2.Объект MessageManager вызывает метод send интерфейса Out boundMessageIF. Он отправляет сообшение и завершает его об работку сообщения.
МОТИВЫ
©Программа должна иметь возможность создавать многочисленные внешние представления одних и тех же данных.
©Классы, содержащие в себе данные, не должны зависеть от какого-либо внешнего представления этихданных и от классов, участвующих в их созда нии. Если классы, инкапсулирующие в себе данные, не зависят от внешних представлений данных, то изменения классов, отвечающих за внешнее представление этих данных, не потребуют изменения классов, отвечающих за их содержимое.
©Классы, отвечающие за создание внешних представлений данных, не зави
сят от классов, инкапсулирующих их в себе. Их экземIUIЯРЫ могут работать
с любым, предоставляющим содержание, объектом, ничего о нем не зная.
РЕШЕНИЕ
На рис. 5.1 1 представлена диаграмма классов, показывающая участников шаб
Лона Builder.
Опишем роли, которые играют эти классы и интерфейсы в шаблоне Builder.
Product. Класс в этой роли определяет тип представления данных. Все классы
Product должны реализовывать интерфейс Product I F таким образом, чтобы
другие классы могли ссылаться на объекты класса Product через интерфейс,
ничего не зная о классе объекта.