2.7. Фасад (Facade)
Шаблона Фасад позволяет скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. Шаблон Фасад строит над набором подсистем интерфейс, причём этот интерфейс может быть абсолютно любым. Допускается существование нескольких фасадов для одного набора подсистем. Клиент вместо прямой работы с подсистемами использует предложенный фасадом интерфейс.
Package A |
Package B |
||
ClassA1 |
ClassA2 |
ClassB1 |
ClassB2 |
Facade
+Operation()
Рис. 7. Дизайн шаблона Фасад.
В качестве иллюстрации применения шаблона Фасад рассмотрим работу с классами системы отправки почтовых сообщений. Письмо, адресат, тело письма, почтовый сервер, присоединённые файлы – все это является отдельным объектами специальных классов. Без применения фасада клиент должен взаимодействовать со всем перечисленным набором объектов, используя их свойстваи методы. Фасад берет работу по взаимодействию на себя – теперь клиент использует только объект-фасад, который делегирует работу нужным подсистемам.
Детали реализации шаблона Фасад не представляют трудностей. Из возможных вариантов отметим прозрачные фасады (в этом случае компоненты подсистемы могут быть доступны и через фасад, и в обход его) и статическиефасады (фасад является статическим классом – скрываемые объекты не агрегируются, а создаются в методах фасада по необходимости).
3.Порождающие шаблоны
Впараграфе рассматривается набор порождающих шаблонов из книги «Design Patterns» и два дополнительных шаблона: Отложенная инициализация и Пул объектов. Шаблоны упорядочены согласно их русскому названию.
19
3.1. Абстрактная фабрика (Abstract factory)
Шаблон Абстрактная фабрика предназначен для создания объектов, принадлежащих одному набору классов и используемых совместно. Абстрактная фабрика переопределяется в конкретных классах-фабриках, создающих объекты одного набора. Этот шаблон изолирует имена классов и их определения от клиента: единственный способ для клиента получить необходимый объект – это воспользоваться одной из реализаций абстрактной фабрики.
Дизайн шаблона Абстрактная фабрика включает большое число участников, однако он достаточно прост (рис. 8). Клиент работает с определённым набором объектов, но использует для этого только реализуемые классами объектов интерфейсы (IProductA и IProductB). Клиент хранит ссылку на конкретную фабрику, реализующую интерфейс IFactory. Для получения нужного объекта клиент вызывает один из методов фабрики.
<<interface>> |
Client |
IFactory |
|
+CreateProductA() |
|
+CreateProductB() |
|
FactoryOne |
FactoryTwo |
<<interface>> |
|
|
IProductA |
+CreateProductA() |
+CreateProductA() |
|
+CreateProductB() |
+CreateProductB() |
ProductA1 |
|
|
ProductA2 |
|
|
<<interface>> |
|
|
IProductB |
|
|
ProductB1 |
ProductB2
Рис. 8. Шаблон абстрактная фабрика.
Рассмотрим пример кода с реализацией шаблона Абстрактная фабрика. Пусть клиент работает с интерфейсами для представления сумок и туфель.
public interface IBag
{
string Material { get; }
}
public interface IShoes
{
int Price { get; }
}
20
Имеется два набора классов, реализующих указанные интерфейсы.
// сумка и туфли Gucci public class GucciBag : IBag
{
public string Material
{
get { return "Crocodile skin"; }
}
}
public class GucciShoes : IShoes
{
public int Price
{
get { return 1000; }
}
}
// сумка и туфли Poochy :) public class PoochyBag : IBag
{
public string Material
{
get { return "Plastic"; }
}
}
public class PoochyShoes : IShoes
{
public int Price
{
get { return 50; }
}
}
Опишем фабричный интерфейс и реализуем две конкретные фабрики.
public interface IFactory
{
IBag CreateBag(); IShoes CreateShoes();
}
public class GucciFactory : IFactory
{
public IBag CreateBag()
{
return new GucciBag();
}
21
public IShoes CreateShoes()
{
return new GucciShoes();
}
}
public class ChinaFactory : IFactory
{
public IBag CreateBag()
{
return new PoochyBag();
}
public IShoes CreateShoes()
{
return new PoochyShoes();
}
}
Код клиента один раз создаёт требуемую фабрику, а далее работает только
синтерфейсами фабрики и товаров.
//можно изменить на factory = new ChinaFactory(); IFactory factory = new GucciFactory();
IBag bag = factory.CreateBag(); IShoes shoes = factory.CreateShoes();
3.2. Одиночка (Singleton)
Шаблон Одиночка гарантирует создание единственного экземпляраобъекта некоторого класса и предоставляет точку доступа для получения этого экземпляра. Существование единственного объекта часто требуется при организации доступа к аппаратному обеспечению, реализации кэша, систем ведения отладочной информации и т. п.
Общая схема шаблона достаточно проста (рис. 9). Конструктор класса объявляется закрытым – создавать объекты могут только методы самого класса. Для хранения единственного экземпляра используется закрытое статическое поле. Для получения экземпляра служит статический метод.
Singleton -instance:Singleton
-Singleton() +GetInstance()
Рис. 9. Схема шаблона Одиночка.
Ниже представлен код, отвечающий описанной схеме шаблона Одиночка.
22
public sealed class Singleton
{
private static Singleton instance;
private Singleton()
{
}
public static Singleton GetInstance()
{
if (instance == null)
{
instance = new Singleton();
}
return instance;
}
}
Данная реализация шаблона имеет важный недостаток – она неустойчива в многопоточных приложениях. Перепишем пример с учётом этого:
public sealed class Singleton
{
private static Singleton instance;
private static readonly object Locker = new object();
private Singleton()
{
}
public static Singleton GetInstance()
{
lock (Locker)
{
return instance ?? (instance = new Singleton());
}
}
}
Приведём ещё два варианта реализации шаблона Одиночка, подходящие для применения в многопоточных приложениях. Сначала используем тот факт, что при наличии в классе статического конструктора компилятор C# генерирует CIL-код, заставляющий откладывать инициализацию статических полей до первого использования класса (т.е. инициализация максимально отложена). Важно и то, что стандартный код инициализации статических полей потокобезопасен.
public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
23