Последнее обновление: 31.10.2015

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

Когда использовать фасад?

Когда имеется сложная система, и необходимо упростить с ней работу. Фасад позволит определить одну точку взаимодействия между клиентом и системой.

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

Когда нужно определить подсистемы компонентов в сложной системе. Создание фасадов для компонентов каждой отдельной подсистемы позволит упростить взаимодействие между ними и повысить их независимость друг от друга.

В UML общую схему фасада можно представить следующим образом:

Формальное определение программы в C# может выглядеть так:

Class SubsystemA { public void A1() {} } class SubsystemB { public void B1() {} } class SubsystemC { public void C1() {} } public class Facade { SubsystemA subsystemA; SubsystemB subsystemB; SubsystemC subsystemC; public Facade(SubsystemA sa, SubsystemB sb, SubsystemC sc) { subsystemA = sa; subsystemB = sb; subsystemC = sc; } public void Operation1() { subsystemA.A1(); subsystemB.B1(); subsystemC.C1(); } public void Operation2() { subsystemB.B1(); subsystemC.C1(); } } class Client { public void Main() { Facade facade = new Facade(new SubsystemA(), new SubsystemB(), new SubsystemC()); facade.Operation1(); facade.Operation2(); } }

Участники

Классы SubsystemA , SubsystemB , SubsystemC и т.д. являются компонентами сложной подсистемы, с которыми должен взаимодействовать клиент

Client взаимодействует с компонентами подсистемы

Facade - непосредственно фасад, который предоставляет интерфейс клиенту для работы с компонентами

Рассмотрим применение паттерна в реальной задаче. Думаю, большинство программистов согласятся со мной, что писать в Visual Studio код одно удовольствие по сравнению с тем, как писался код ранее до появления интегрированных сред разработки. Мы просто пишем код, нажимаем на кнопку и все - приложение готово. В данном случае интегрированная среда разработки представляет собой фасад, который скрывает всю сложность процесса компиляции и запуска приложения. Теперь опишем этот фасад в программе на C#:

Class Program { static void Main(string args) { TextEditor textEditor = new TextEditor(); Compiller compiller = new Compiller(); CLR clr = new CLR(); VisualStudioFacade ide = new VisualStudioFacade(textEditor, compiller, clr); Programmer programmer = new Programmer(); programmer.CreateApplication(ide); Console.Read(); } } // текстовый редактор class TextEditor { public void CreateCode() { Console.WriteLine("Написание кода"); } public void Save() { Console.WriteLine("Сохранение кода"); } } class Compiller { public void Compile() { Console.WriteLine("Компиляция приложения"); } } class CLR { public void Execute() { Console.WriteLine("Выполнение приложения"); } public void Finish() { Console.WriteLine("Завершение работы приложения"); } } class VisualStudioFacade { TextEditor textEditor; Compiller compiller; CLR clr; public VisualStudioFacade(TextEditor te, Compiller compil, CLR clr) { this.textEditor = te; this.compiller = compil; this.clr = clr; } public void Start() { textEditor.CreateCode(); textEditor.Save(); compiller.Compile(); clr.Execute(); } public void Stop() { clr.Finish(); } } class Programmer { public void CreateApplication(VisualStudioFacade facade) { facade.Start(); facade.Stop(); } }

В данном случае компонентами системы являются класс текстового редактора TextEditor, класс компилятора Compiller и класс общеязыковой среды выполнения CLR. Клиентом выступает класс программиста, фасадом - класс VisualStudioFacade, который через свои методы делегирует выполнение работы компонентам и их методам.

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

Почитать описание других паттернов.

Проблема

Минимизировать зависимость подсистем некоторой сложной системы и обмен информацией между ними.

Описание

При проектировании сложных систем, зачастую применяется т.н. принцип декомпозиции, при котором сложная система разбивается на более мелкие и простые подсистемы. Причем, уровень декомпозиции (ее глубину) определяет исключительно проектировщик. Благодаря такому подходу, отдельные компоненты системы могу быть разработаны изолированно, затем интегрированы вместе. Однако возникает, очевидная на первый взгляд, проблема - высокая связность модулей системы. Это проявляется, в первую очередь, в большом объеме информации, которой модули обмениваются друг с другом. К тому же, для подобной коммуникации одни модули должны обладать достаточной информацией о природе других модулей.

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

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

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

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

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

Используя паттерн «Фасад», реализуем унифицированный интерфейс к некоторой подсистеме авторизации пользователей. Сама подсистема авторизации (в данном примере), безусловно не претендует на «сложную систему», однако она отчетливо отображает основные достоинства паттерна.

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

Рассмотрим диаграмму. Каркас подсистемы авторизации, для наглядности, выделен в прямоугольник. Фасад Authorizator предоставляет клиенту унифицированный интерфейс для работы с подсистемой. В данном случае, это всего один метод - authorizate(), однако их могло быть и больше. При этом, клиент может использовать фасад для работы с подсистемой, а может, непосредственно пользоваться классами, составляющими ее. Сам процесс авторизации достаточно прост. На основании имени пользователя ищется соответствующая запись в базе данных, посредством интерфейса DB. Затем, сравнивается пароль найденной записи с паролем указанным пользователем.

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

В коде реализации нет класса PgSQLDB.

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 .

PS : У меня у одного хабраредактор не работает?

Описание Remote Facade

Предоставляет общий объединяющий интерфейс для набора методов объекта для улучшения эффективности сетевого взаимодействия.

Паттерн Remote Facade в объектно-ориентированной модели улучшает работу с маленькими объектами, у которых маленькие методы. Маленькие методы открывают большие возможности для контроля и изменения поведения, а также для улучшения понимания клиентом работы приложения. Одно из последствий такого "мелко-молотого" поведения в том, что обычно происходит много взаимодействий между объектами с вызовом множества методов.

В одном адресном пространстве "мелко-молотые" взаимодействия работаю хорошо, но всё меняется, когда происходит взаимодействие между процессами. Удалённые вызовы более затратны, потому что многое надо сделать: иногда данные нужно упорядочить, проверить на безопасность, пакеты должны быть маршрутизированы на свичах. Если два процесса работают на разных краях света, даже скорость света может играть роль. Тяжелая правда в том, что любые межпроцессные взаимодействия на порядок более расточительны, чем анутрипроцессные вызовы. Даже, если оба процесса работают на одной машине. Такое влияние на производительность не может быть упущено из вида, даже приверженцами ленивой оптимизации.

В результате любой объект, который задействован в удалённом взаимодействии, нуждается в более общем интерфейсе, который бы позволил минимизировать количество запросов, необходимых, чтобы сделать что-либо. Это затрагивает не только методы, но и объекты. Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта. Надо забыть о благой цели малых объектов и малых методов. Программирование становится всё сложнее, продуктивность падает и падает.

Паттерн Remote Facade представляет собой общий "Фасад" (по GoF) поверх структуры более "мелко-молотых" объектов. Ни один из этих объектов не имеет удалённого интерфейса, а Remote Facade не включает в себя никакой бизнес-логики. Всё, что делает Remote Facade - это транслирует общие запросы в набор небольших запросов к подчинённым объектам.

Фасад (Facade).

Тип

Структурный шаблон проектирования (Structural).

Описание

Шаблон Фасад объединяет группу объектов в рамках одного специализированного интерфейса и переадресует вызовы его методов к этим объектам.

Шаблон используется если необходимо:

• упростить доступ к сложной системе;
• (или) создать различные уровни доступа к системе;
• (или) уменьшить число зависимостей между системой и клиентом.

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

Назначение Фасада – создать интерфейс, содержащий методы для решения определённой задачи или предоставляющий определённую абстракцию исходной системы. При этом возможно следующее:

• переадресация вызовов интерфейса шаблона объектам системы;
• уменьшение числа параметров метода подстановкой заранее определенных значений;
• создание новых методов, которые объединяют вызовы объектов системы и/или добавляют свою логику;
• часть исходных методов и свойств будут недоступны через Фасад, т.к. не играют роли для решения поставленной задачи.

Такой подход упрощает использование сложной системы. Одновременно это понижает количество вызываемых методов и общее число их вызовов. В итоге – уменьшение числа зависимостей в приложении.

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

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

Интересен вариант совместного использования шаблонов Фасад и Абстрактной фабрики . В этом случае интерфейс Фасада связан не с самими объектами, а с их интерфейсами. Это скрывает реализацию и дает Абстрактной фабрике возможность изменять ее. Такой подход можно встретить, например, когда система использует платформенно- или аппаратно-зависимые классы.

Схожие шаблоны и их отличия

Фасад	Объединяет группу объектов под одним специализированным интерфейсом.	Упрощает работу с группой объектов, вносит новый уровень абстракции.	Содержит или ссылается на объекты, необходимые для реализации специализированного интерфейса.
Адаптер	Изменяет интерфейс объекта не изменяя его функциональности. Может адаптировать несколько объектов к одному интерфейсу.	Позволяет повторно использовать уже существующий код.	Содержит или наследует адаптируемый объект.
Мост	Разделяет объект на абстракцию и реализацию. Используется для иерархии объектов.	Позволяет отдельно изменять (наследовать) абстракцию и реализацию, повышая гибкость системы.	Содержит объект(реализацию), который предоставляет методы для заданной абстракций и ее уточнений (наследников).
Декоратор	Расширяет возможности объекта, изменяет его поведение. Поддерживает интерфейс декорируемого объекта, но может добавлять новые методы и свойства.	Дает возможность динамически менять функциональность объекта. Является альтернативой наследованию (в том числе множественному).	Содержит декорируемый объект. Возможна цепочка объектов, вызываемых последовательно.
Прокси	Прозрачно замещает объект и управляет доступом к нему. Не изменяет интерфейс или поведение.	Упрощает и оптимизирует работу с объектом. Может добавлять свою функциональность, скрывая ее от клиента.	Содержит объект или ссылку на него, может управлять существованием замещенного объекта.
Компоновщик	Предоставляет единый интерфейс для взаимодействия с составными объектами и их частями.	Упрощает работу клиента, позволяет легко добавлять новые варианты составных объектов и их частей.	Включается в виде интерфейса в составные объекты и их части.
Приспособленец	Не ставит целью изменение интерфейса объекта. Но это может потребоваться для получения обратно данных из вынесенной части состояния.	Позволяет уменьшить число экземпляров объекта в приложении и тем самым сэкономить его ресурсы.	Выносит контекстно-зависимую часть состояния объекта вовне, заменяя несколько его экземпляров одним.

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

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

Реализация шаблона в общем виде

Возможны следующие подходы к реализации шаблона:

1. Создание отдельного класса, который ссылается на экземпляр системы. Это классический вариант и реализация отчетливо выделена, т.к. является отдельным объектом. public class FacadeImpl: IFacade { private AppSubSystem _system; public FacadeImpl(AppSubSubSystem s) { this._system = s; } /* Skipped */ } Кроме того, экземпляр системы может создаваться внутри Фасада: public class FacadeImpl: IFacade { private readonly AppSubSystem _system = new AppSubSystem(); /* Skipped */ }
2. Добавление интерфейса Фасада в систему. Может пригодиться, если у Фасада много клиентов и нет смысла создавать каждому по собственному экземпляру реализации шаблона. public class AppSubSystem { public IFacade FacadeInterface { get; private set; } public AppSubSystem () { this.FacadeInterface = new FacadeImpl(this); } /* Skipped */ }
3. Поддержка интерфейса Фасада в классе самой системы, используя наследование. Реализация получается "размытой" по системе. Однако, теперь ее экземпляр может использоваться там, где требуется интерфейс Фасада. Кроме того, появляется возможность доступа к закрытым полям и методам системы, а так же нет необходимости переадресации вызовов одинаковых методов. public class AppSubSystem: IFacade { /* Skipped */ }

Все указанные подходы можно записать следующим образом:

• определяем функции выделяемой задачи или новой абстракции;
• согласуем их с существующими объектами в системе;
• разрабатываем интерфейс шаблона ;
• реализуем в одном из вариантов:
  • отдельный класс, переадресовывающего вызовы к объектам системы;
  • в классе самой системы;
• клиент, вместо взаимодействия с несколькими классами, работает с одним новым интерфейсом.

Пример реализации

Рассмотрим пример создания простого редактора сообщений блога в рамках системы управления сайтом. Перечислим какие объекты будут входить в состав этой подсистемы. Авторизацию и прочие несущественные для примера методы уберем для краткости изложения.

Начнем с основного – записи в блог, представленной классом BlogPost. Этот класс хранит свойства и содержимое одной записи.

Public class BlogPost { ///

Gets or sets the post properties.

public BlogPostProperties Properties { get; set; } ///

Gets or sets the post content.

public BlogPostContent Content { get; set; } }

Следующий класс BlogPostStorage – хранилище для записей блога на сервере. Он позволяет задавать данные для авторизации, загружать и публиковать записи.

Public class BlogPostStorage { ///

public string Server { get; set; } ///

Gets or sets the blogger"s login.

public string Login { get; set; } ///

Gets or sets the blogger"s password.

public string Password { private get; set; } ///

/// The start date. /// The end date. /// public List GetPostList(DateTime startDate, DateTime endDate) { /* Skipped */ } ///

Gets the post associated with the specified id.

/// The id of the post to get. /// The instance for the id. public BlogPost GetPost(int postId) { /* Skipped */ } ///

Deletes the post associated with the specified id.

/// The id of the post to delete. public void DeletePost(int postId) { /* Skipped */ } ///

Publishes the specified post.

/// The post to publish. public void Publish(BlogPost post) { /* Skipped */ } }

Для проверки орфографии есть простой класс SimpleSpellChecker .

Public class SimplepellChecker { ///

Checks the word for spelling errors.

/// The word to check. /// When this method returns, contains the suggestions /// for the specified word. /// true on correct word; otherwise, false public bool Check(string word, out List suggestions) { /* Skipped */ } }

И последний из компонентов – текстовый редактор. Уберем практически все его методы для краткости.

Public class PostEditor { ///

Spell checker.

private readonly SimpleSpellChecker _spellChecker = new SimpleSpellChecker(); ///

public bool IsSpellCheckComplete { get; private set; } ///

Gets or sets the post to edit.

public BlogPost Post { get; set; } ///

Gets the post properties.

public BlogPostProperties PostProperties { get { if (this.Post == null) { return null; } return this.Post.Properties; } } ///

Gets the post content.

public BlogPostContent PostContent { get { if (this.Post == null) { return null; } return this.Post.Content; } } }

Перейдем к редактору записей блога. Его подсистема будет выглядеть следующим образом:

Public class BlogEditor { private readonly BlogPostStorage _storage = new BlogPostStorage(); public BlogPostStorage Storage { get { return this._storage; } } private readonly PostEditor _editor = new PostEditor(); public PostEditor Editor { get { return this._editor; } } }

Клиент может непосредственно использовать эти объекты. Но нужно ли ему это? Если посмотреть внимательно, то выяснится что необходимы следующие функции:

• указать реквизиты для входа на сервер: Server , Login , Password ;
• загрузить список записей: GetPostList() ;
• загрузить запись для редактирования: LoadPost() ;
• получить свойства записи и ее текст: PostProperties , PostContent ;
• убедиться что орфография записи проверена: IsSpellCheckComplete ;
• опубликовать запись: Publish() ;
• удалить запись: DeletePost() .

Все это можно записать в виде интерфейса для Фасада:

Public interface IBlogEditorFacade { ///

Gets or sets the server address.

string Server { get; set; } ///

Sets the blogger"s login.

string Login { set; } ///

Sets the blogger"s password.

string Password { set; } ///

Gets a value indicating whether spell check is complete.

bool IsSpellCheckComplete { get; } ///

Gets the current post properties.

BlogPostProperties PostProperties { get; } ///

Gets the current post content.

BlogPostContent PostContent { get; } ///

Returns the list that represents the collection of post on server /// for a specified period of time.

/// The start date. /// The end date. /// The list that represents the collection of post on server. List GetPostList(DateTime startDate, DateTime endDate); ///

Loads the specified post.

/// The id of the post to get. void LoadPost(int postId); ///

Publishes the current post to blog.

void Publish(); ///

Deletes the specified post.

/// The id of the post to delete. void DeletePost(int postId); }

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

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

Initializes a new instance of the /// class.

/// Reference to a blog editor instance. public BlogEditorFacade(BlogEditor blogEditor) { if (blogEditor == null) { throw new ArgumentNullException("blogEditor can"t be null"); } this._blogEditor = blogEditor; } public string Server { get { return this._blogEditor.Storage.Server; } set { this._blogEditor.Storage.Server = value; } } public void LoadPost(int postId) { BlogPost post = this._blogEditor.Storage.GetPost(postId); if (post != null) { this._blogEditor.Editor.Post = post; } } /* IBlogEditorFacade implementation skipped */ }

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

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 можно передать любого его потомка.

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

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

11 марта 2010 в 10:30

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

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

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

Проблема

Минимизировать зависимость подсистем некоторой сложной системы и обмен информацией между ними.

Описание

При проектировании сложных систем, зачастую применяется т.н. принцип декомпозиции, при котором сложная система разбивается на более мелкие и простые подсистемы. Причем, уровень декомпозиции (ее глубину) определяет исключительно проектировщик. Благодаря такому подходу, отдельные компоненты системы могу быть разработаны изолированно, затем интегрированы вместе. Однако возникает, очевидная на первый взгляд, проблема - высокая связность модулей системы. Это проявляется, в первую очередь, в большом объеме информации, которой модули обмениваются друг с другом. К тому же, для подобной коммуникации одни модули должны обладать достаточной информацией о природе других модулей.

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

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

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

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

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

Используя паттерн «Фасад», реализуем унифицированный интерфейс к некоторой подсистеме авторизации пользователей. Сама подсистема авторизации (в данном примере), безусловно не претендует на «сложную систему», однако она отчетливо отображает основные достоинства паттерна.

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

Рассмотрим диаграмму. Каркас подсистемы авторизации, для наглядности, выделен в прямоугольник. Фасад Authorizator предоставляет клиенту унифицированный интерфейс для работы с подсистемой. В данном случае, это всего один метод - authorizate(), однако их могло быть и больше. При этом, клиент может использовать фасад для работы с подсистемой, а может, непосредственно пользоваться классами, составляющими ее. Сам процесс авторизации достаточно прост. На основании имени пользователя ищется соответствующая запись в базе данных, посредством интерфейса DB. Затем, сравнивается пароль найденной записи с паролем указанным пользователем.

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

В коде реализации нет класса PgSQLDB.

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 .

PS : У меня у одного хабраредактор не работает?