Как называется этот шаблон дизайна? Фасад, адаптер, мост, прокси?
В одном из моих проектов я использую следующий шаблон в нескольких местах: у меня есть класс A с кучей методов и класса B который создается с указателем на некоторый экземпляр Aэкспорт только подмножества этих методов для пользователя (который не является владельцем A пример).
class A
{
public:
void doStuff();
void doOtherStuff();
void doYetOtherStuff();
B getB()
{
return B(this);
}
};
class B
{
friend class A;
public:
void doStuff()
{
_a->doStuff();
}
void doOtherStuff()
{
_a->doOtherStuff();
}
private:
B(A* a) : _a(a) {}
A* _a;
};
Экземпляр A может быть создан моей библиотекой, например, и созданным экземпляром B (связано с A) может быть передан плагину, который все еще будет иметь доступ к A Например, хотя и в ограниченной форме.
Я просто запутался в отношении название шаблона дизайна из B: это фасад, мост, адаптер или прокси? Или что-то другое?
Решение
В этом случае я бы посоветовал проверить Huston Design Patterns. В конце каждого паттерна он ссылается на GoF и дает различия между текущим и связанным паттернами.
Например, на Прокси мы можем прочитать:
Адаптер предоставляет другой интерфейс для своей темы. Прокси предоставляет тот же интерфейс. Декоратор предоставляет расширенный интерфейс. [GoF. P216]
Поэтому, так как вы ограничение Интерфейс это ближе к адаптеру, хотя нам еще нужно проверить мост и фасад.
Если мы проверим Адаптер, мы получим другие самородки:
Мост спроектирован заранее, чтобы абстракция и реализация могли варьироваться независимо. Адаптер модернизирован для совместной работы несвязанных классов. [GoF, p161]
Фасад определяет новый интерфейс, в то время как Adapter использует старый интерфейс. Помните, что Adapter позволяет двум существующим интерфейсам работать вместе, а не определять совершенно новый. [GoF, стр. 219]
Однако они не такие впечатляющие. На данный момент это менее ясно, потому что дизайн не является единственным вкладчиком в имя, намерение также имеет значение. Фасад — это скрывающая сложность, а Мост — о декорреляции ортогональных размеров: здесь тоже не применимо.
Таким образом, мы остались с адаптер.
Другие решения
Без какого-либо контекста я бы назвал это делегатом. B делегирует ответственность за выполнение дела A.
Это чрезвычайно распространенный шаблон в программировании Какао / UIKit, особенно если A является довольно абстрактным типом — это было бы в большей степени, если бы A был просто интерфейсом, который мог бы реализовать любой класс.
Однако, если вы упрощаете интерфейс и особенно если жизненный цикл B короткий (просто существует для упрощения доступа к A), тогда да, это шаблон фасада.
Что касается других шаблонов — ни один полностью не исключен, но вот мои мысли:
Адаптер обычно меняет интерфейс — то есть клиент B хочет вызвать doStuff (), но у A есть какой-то другой интерфейс (возможно, более сложный или специфичный для домена), с которым клиент не хочет иметь дело, поэтому B адаптирует интерфейс A к интерфейсу, который хочет клиент.
Прокси обычно включает представление некоторого удаленного или менее доступного или инстанцируемого объекта; Доступность A делает его менее похожим на образец прокси-сервера, но прокси-сервер может, конечно, обернуть вызов API с тем же именем.
Если реализация A может варьироваться и B скрывает этот факт от клиента, это может указывать на шаблон стратегии.