Реализуем данный интерфейс. Созданные методы и свойства достаточно простые. Они просто переадресуют запрос к нужному объекту в системе. Поэтому сократим приведенный код для краткости. оставим только конструктор, и по одному свойству и методу.

Public class BlogEditorFacade: IBlogEditorFacade { private BlogEditor _blogEditor; ///

В конструкторе класса указывается экземпляр системы, к которому Фасад должен обеспечить доступ. Теперь код клиента может использовать интерфейс для упрощения доступа:

Public class BlogClient { private readonly IBlogEditorFacade _blogEditor = null; public BlogClient(IBlogEditorFacade iBlogEditor) { this._blogEditor = iBlogEditor; } public bool ValidateAndPublish() { bool isPostValid = true; BlogPostContent content = this._blogEditor.PostContent; /// TODO: Validate the content if (isPostValid) { this._blogEditor.Publish(); } return isPostValid; } }

Использование BlogClient выглядит следующим образом:

BlogEditor blogEditorObject = new BlogEditor(); /// ... BlogClient blogClient = new BlogClient(new BlogEditorFacade(blogEditorObject));

Обратите внимание, что в конструктор Фасада передается интерфейс. Кроме того, создание объекта системы (BlogEditor ) вынесено из реализации шаблона.

Таком образом клиент использует только интерфейс, который был для него создан, для работы с системой. Так же уменьшена зависимость реализации шаблона от реализации системы. Ведь вместо экземпляра BlogEditor можно передать любого его потомка.

Однако в некоторых случаях выгоднее создавать объект внутри самого шаблона. Например, чтобы каждый экземпляр Фасада имел свой экземпляр системы или чтобы, при необходимости, скрыть используемую систему от клиентов.

Возвращаясь к рассматриваемому примеру, можно отметить что, взаимодействие с системой стало проще. Количество методов и вызовов методов ее объектов уменьшилось. Цель применения шаблона достигнута.

Перед прочтением ознакомьтесь с , в котором описаны принятые соглашения и понятия. Данная статья дополняется с некоторой периодичностью, так что если вы ее читали ранее, не факт что данные не изменились.

Facade (Фасад) относиться к классу структурных паттернов. Представляет собой унифицированный интерфейс вместо набора интерфейсов некоторой подсистемы. Паттерн фасад определяет интерфейс более высокого уровня, который упрощает использование подсистем.

Разбиение на подсистемы сложной системы позволяет упростить процесс проектирования, а также помогает максимально снизить зависимости одной подсистемы от другой. Однако это приводит к тому, что использовать такие подсистемы вместе становиться довольно сложно. Один из способов решения этой проблемы является ввод паттерна фасад.

Это один из тех паттернов, у которого нет четкой реализации, так как она зависит от конкретной системы. В общем случае нам надо выполнить такое преобразование:

В сером прямоугольнике находятся наши подсистемы, которые имеют некоторые зависимости между собой (могут и не иметь). Тремя верхними блоками обозначаются три участка клиентского кода, в которых он взаимодействует с этой подсистемой. Наша задача, сделать простой, единый интерфейс, через которого было бы достаточно для взаимодействия с подсистемами в рамках поставленной задачи, т.е. нам не нужно делать универсальный интерфейс, на все случаи жизни, так как это в большинстве случаев излишне и ведет к усложнению взаимодействия, увеличению времени разработки.

Ниже приведен набросок одной из реализаций:

/** * SystemA */ class Bank { public function OpenTransaction() {} public function CloseTransaction() {} public function transferMoney($amount) {} } /** * SystemB */ class Client { public function OpenTransaction() {} public function CloseTransaction() {} public function transferMoney($amount) {} } /** * SystemC */ class Log { public function logTransaction() {} } class Facade { public function transfer($amount) { $Bank = new Bank(); $Client = new Client(); $Log = new Log(); $Bank->OpenTransaction(); $Client->OpenTransaction(); $Log->logTransaction("Transaction open"); $Bank->transferMoney(-$amount); $Log->logTransaction("Transfer money from bank"); $Client->transferMoney($amount); $Log->logTransaction("Transfer money to client"); $Bank->CloseTransaction(); $Client->CloseTransaction(); $Log->logTransaction("Transaction close"); } } // Client code $Transfer = new Facade(); $Transfer->transfer(1000);

Назначение паттерна Facade

• Паттерн Facade предоставляет унифицированный интерфейс вместо набора интерфейсов некоторой подсистемы. Facade определяет интерфейс более высокого уровня, упрощающий использование подсистемы.
• Паттерн Facade "обертывает" сложную подсистему более простым интерфейсом.

Решаемая проблема

Клиенты хотят получить упрощенный интерфейс к общей функциональности сложной подсистемы.

Обсуждение паттерна Facade

Паттерн Facade инкапсулирует сложную подсистему в единственный интерфейсный объект. Это позволяет сократить время изучения подсистемы, а также способствует уменьшению степени связанности между подсистемой и потенциально большим количеством клиентов. С другой стороны, если фасад является единственной точкой доступа к подсистеме, то он будет ограничивать возможности, которые могут понадобиться "продвинутым" пользователям.

Объект Facade, реализующий функции посредника, должен оставаться довольно простым и не быть всезнающим "оракулом".

Структура паттерна Facade

Клиенты общаются с подсистемой через Facade. При получении запроса от клиента объект Facade переадресует его нужному компоненту подсистемы. Для клиентов компоненты подсистемы остаются "тайной, покрытой мраком".

Подсистемы SubsystemOne и SubsystemThree не взаимодействуют напрямую с внутренними компонентами подсистемы SubsystemTwo. Они используют "фасад" SubsystemTwoWrapper (т.е. абстракцию более высокого уровня).

Паттерн Facade определяет унифицированный высокоуровневый интерфейс к подсистеме, что упрощает ее использование. Покупатели сталкиваются с фасадом при заказе каталожных товаров по телефону. Покупатель звонит в службу поддержки клиентов и перечисляет товары, которые хочет приобрести. Представитель службы выступает в качестве "фасада", обеспечивая интерфейс к отделу исполнения заказов, отделу продаж и службе доставки.

• Определите для подсистемы простой, унифицированный интерфейс.
• Спроектируйте класс "обертку", инкапсулирующий подсистему.
• Вся сложность подсистемы и взаимодействие ее компонентов скрыты от клиентов. "Фасад" / "обертка" переадресует пользовательские запросы подходящим методам подсистемы.
• Клиент использует только "фасад".
• Рассмотрите вопрос о целесообразности создания дополнительных "фасадов".

Особенности паттерна Facade

• Facade определяет новый интерфейс, в то время как Adapter использует уже имеющийся. Помните, Adapter делает работающими вместе два существующих интерфейса, не создавая новых.
• Если Flyweight показывает, как сделать множество небольших объектов, то Facade показывает, как сделать один объект, представляющий целую подсистему.
• Mediator похож на Facade тем, что абстрагирует функциональность существующих классов. Однако Mediator централизует функциональность между объектами-коллегами, не присущую ни одному из них. Коллеги обмениваются информацией друг с другом через Mediator. С другой стороны, Facade определяет простой интерфейс к подсистеме, не добавляет новой функциональности и не известен классам подсистемы.
• Abstract Factory может применяться как альтернатива Facade для сокрытия платформенно-зависимых классов.
• Объекты "фасадов" часто являются Singleton , потому что требуется только один объект Facade.
• Adapter и Facade в являются "обертками", однако эти "обертки" разных типов. Цель Facade - создание более простого интерфейса, цель Adapter - адаптация существующего интерфейса. Facade обычно "обертывает" несколько объектов, Adapter "обертывает" один объект.

Реализация паттерна Facade

Разбиение системы на компоненты позволяет снизить ее сложность. Ослабить связи между компонентами системы можно с помощью паттерна Facade. Объект "фасад" предоставляет единый упрощенный интерфейс к компонентам системы.

В примере ниже моделируется система сетевого обслуживания. Фасад FacilitiesFacade скрывает внутреннюю структуру системы. Пользователь, сделав однажды запрос на обслуживание, затем 1-2 раза в неделю в течение 5 месяцев справляется о ходе выполнения работ до тех пор, пока его запрос не будет полностью обслужен.

#include class MisDepartment { public: void submitNetworkRequest() { _state = 0; } bool checkOnStatus() { _state++; if (_state == Complete) return 1; return 0; } private: enum States { Received, DenyAllKnowledge, ReferClientToFacilities, FacilitiesHasNotSentPaperwork, ElectricianIsNotDone, ElectricianDidItWrong, DispatchTechnician, SignedOff, DoesNotWork, FixElectriciansWiring, Complete }; int _state; }; class ElectricianUnion { public: void submitNetworkRequest() { _state = 0; } bool checkOnStatus() { _state++; if (_state == Complete) return 1; return 0; } private: enum States { Received, RejectTheForm, SizeTheJob, SmokeAndJokeBreak, WaitForAuthorization, DoTheWrongJob, BlameTheEngineer, WaitToPunchOut, DoHalfAJob, ComplainToEngineer, GetClarification, CompleteTheJob, TurnInThePaperwork, Complete }; int _state; }; class FacilitiesDepartment { public: void submitNetworkRequest() { _state = 0; } bool checkOnStatus() { _state++; if (_state == Complete) return 1; return 0; } private: enum States { Received, AssignToEngineer, EngineerResearches, RequestIsNotPossible, EngineerLeavesCompany, AssignToNewEngineer, NewEngineerResearches, ReassignEngineer,EngineerReturns, EngineerResearchesAgain, EngineerFillsOutPaperWork, Complete }; int _state; }; class FacilitiesFacade { public: FacilitiesFacade() { _count = 0; } void submitNetworkRequest() { _state = 0; } bool checkOnStatus() { _count++; /* Запрос на обслуживание получен */ if (_state == Received) { _state++; /* Перенаправим запрос инженеру */ _engineer.submitNetworkRequest(); cout << "submitted to Facilities - " << _count << " phone calls so far" << endl; } else if (_state == SubmitToEngineer) { /* Если инженер свою работу выполнил, перенаправим запрос электрику */ if (_engineer.checkOnStatus()) { _state++; _electrician.submitNetworkRequest(); cout << "submitted to Electrician - " << _count << " phone calls so far" << endl; } } else if (_state == SubmitToElectrician) { /* Если электрик свою работу выполнил, перенаправим запрос технику */ if (_electrician.checkOnStatus()) { _state++; _technician.submitNetworkRequest(); cout << "submitted to MIS - " << _count << " phone calls so far" << endl; } } else if (_state == SubmitToTechnician) { /* Если техник свою работу выполнил, то запрос обслужен до конца */ if (_technician.checkOnStatus()) return 1; } /* Запрос еще не обслужен до конца */ return 0; } int getNumberOfCalls() { return _count; } private: enum States { Received, SubmitToEngineer, SubmitToElectrician, SubmitToTechnician }; int _state; int _count; FacilitiesDepartment _engineer; ElectricianUnion _electrician; MisDepartment _technician; }; int main() { FacilitiesFacade facilities; facilities.submitNetworkRequest(); /* Звоним, пока работа не выполнена полностью */ while (!facilities.checkOnStatus()) ; cout << "job completed after only " << facilities.getNumberOfCalls() << " phone calls" << endl; }

Вывод программы:

submitted to Facilities - 1 phone calls so far submitted to Electrician - 12 phone calls so far submitted to MIS - 25 phone calls so far job completed after only 35 phone calls

Паттерн проектирования «Фасад» / «Facade»

• Совершенный код

Описание других паттернов.

Проблема

Описание

Таким образом, минимизация зависимости подсистем, а также снижение объема передаваемой между ними информации - одна из основных задач проектирования.

Один из способов решения данной задачи - использование паттерна «Фасад».

Паттерн «Фасад» предоставляет унифицированный интерфейс вместо набора интерфейсов некоторой подсистемы. Фасад определяет интерфейс более высокого уровня, кото-
рый упрощает использование подсистемы.

Практическая задача

Диаграмма классов

Реализация на С#

using System;
using System.Collections.Generic ;
using System.Linq;
using System.Text;
using System.Security;

namespace Facade
{
//Абстрактный класс пользователя
abstract class User
{
protected string username;
protected string passwd;

public abstract string getUserRole();

public string getPasswdHash()
{
// Это строка не несет какой-либой смысловой нагрузки.
// Безусловно, таким образом мы получаем небезопасный хеш-код пароля
return passwd.GetHashCode().ToString();
}
}

// Уточнение пользователя, в качестве пользователя по-умолчанию
class DefaultUser: User
{
public DefaultUser(string username, string passwd)
{
this .username = username;
this .passwd = passwd;
}

{
return "DEFAULT_USER" ;
}
}

// Уточнение пользователя, в качестве администратора
class Administrator: User
{
public Administrator(string username, string passwd)
{
this .username = username;
this .passwd = passwd;
}

public override string getUserRole()
{
return "ADMINISTRATOR" ;
}

// Интерфейс доступа к базе данных
interface DB
{
User search(string username);
}

// Реализация интерфейса БД для SQLite
class SQLiteDB: DB
{
public SQLiteDB(string filename)
{
// Инициализация драйвера БД
}

public User search(string username)
{
// Заглушка
throw new NotImplementedException();
}
}

// Авторизация пользователя
public void authorizate(string username, string passwd)
{
DB db = new SQLiteDB("db.sqlite" );
User user = db.search(username);
if (user.getPasswdHash() == passwd)
{
// все хорошо, пользователь опознан
}
else
{
// что-то пошло не так
throw new SecurityException("Wrong password or username!" );
}
}
}

class Program
{
static void Main(string args)
{
// Вымышленный пользователь
string username = "Vasya" ;
string passwd = "qwerty" .GetHashCode().ToString();

Authorizator auth = new Authorizator();
try
{
auth.authorizate(username, passwd);
}
catch (SecurityException ex)
{
// Пользователь не прошел аутентификацию
}
}
}
}

* This source code was highlighted with Source Code Highlighter .