 |
Паттерны. Factory method. Prototype. Flyweight. Mediator
|
|
|
|
Паттерны
Идиомы – часть языка. Каждый ЯП предлагает свои концепции.
Арихитектурный принципы проектирования –
Design Patterns
Любой паттерн проектирования, используемый при разработке информационных систем, представляет собой формализованное описание часто встречающейся задачи проектирования, удачное решение данной задачи, а также рекомендации по применению этого решения в различных ситуациях. Кроме того, паттерн проектирования обязательно имеет общеупотребимое наименование. Правильно сформулированный паттерн проектирования позволяет, отыскав однажды удачное решение, пользоваться им снова и снова. Следует подчеркнуть, что важным начальным этапом при работе с паттернами является адекватное моделирование рассматриваемой предметной области. Это является необходимым как для получения должным образом формализованной постановки задачи, так и для выбора подходящих паттернов проектирования. В качестве примера монографии, в которой описаны основы построения модели анализа и модели проектирования, можно привести работу [*]
[*] К. Ларман. Применение UML и паттернов проектирования. М. , Вильямс, 2002.
FACTORY METHOD
In general, all subclasses in a class hierarchy inherit the methods implemented
by the parent class. A subclass may override the parent class implementation to
offer a different type of functionality for the same method. When an application
object is aware of the exact functionality it needs, it can directly instantiate the
class from the class hierarchy that offers the required functionality.
At times, an application object may only know that it needs to access a class
from within the class hierarchy, but does not know exactly which class from
among the set of subclasses of the parent class is to be selected.
PROTOTYPE
-When a client needs to create a set of objects that are alike or differ from
each other only in terms of their state and it is expensive to create such
objects in terms of the time and the processing involved.
-As an alternative to building numerous factories that mirror the classes to
|
|
|
be instantiated (as in the Factory Method).
In such cases, the Prototype pattern suggests to:
-Create one object upfront and designate it as a prototype object.
-Create other objects by simply making a copy of the prototype object and
making required modifications.
FLYWEIGHT
Consider an application scenario that involves creating a large number of
objects that are unique only in terms of a few parameters. In other words, these
objects contain some intrinsic, invariant data that is common among all objects.
This intrinsic data needs to be created and maintained as part of every object
that is being created. The overall creation and maintenance of a large group of
such objects can be very expensive in terms of memory-usage and performance.
The Flyweight pattern can be used in such scenarios to design a more efficient
way of creating objects.
The Flyweight pattern suggests separating all the intrinsic common data into
a separate object referred to as a Flyweight object. The group of objects being
created can share the Flyweight object as it represents their intrinsic state. This
eliminates the need for storing the same invariant, intrinsic information in every
object; instead it is stored only once in the form of a single Flyweight object.
As a result, the client application can realize considerable savings in terms of the
memory-usage and the time.
Mediator
The Mediator pattern suggests abstracting all object interaction details into a
separate class, referred to as a Mediator, with knowledge about the interacting
group of objects. Every object in the group is still responsible for offering the
service it is designed for, but objects do not interact with each other directly for
this purpose. The interaction between any two different objects is routed through
the Mediator class. All objects send their messages to the mediator. The mediator
then sends messages to the appropriate objects as per the application’s requirements.
The resulting design has the following major advantages:
-With all the object interaction behavior moved into a separate (mediator)
object, it becomes easier to alter the behavior of object interrelationships,
by replacing the mediator with one of its subclasses with extended or
altered functionality.
-Moving interobject dependencies out of individual objects results in
enhanced object reusability.
-Because objects do not need to refer to each other directly, objects can
be unit tested more easily.
-The resulting low degree of coupling allows individual classes to be
modified without affecting other classes.
|
|
|
