Фасад против.Посредник
https://stackoverflow.com/questions/481984
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я исследовал разницу между этими двумя шаблонами.
Я понимаю, что фасад инкапсулирует доступ к подсистеме, а посредник инкапсулирует взаимодействие между компонентами.
Я понимаю, что компоненты подсистемы не знают о фасаде, тогда как компоненты явно знают о посреднике.
В настоящее время я использую фасад для инкапсуляции метода получения информации о конфигурации, например.App.Config, пользовательские настройки, хранящиеся в SQL, информация о сборке и т. д., а также посредник для навигации между различными формами окон.
Однако большинство сайтов отмечают, что медиатор «добавляет функционал».Что они имеют в виду под этим?Как медиатор добавляет функциональность?
Решение
...большинство сайтов отмечают, что медиатор «добавляет функциональности»…
А фасад только раскрывает существующую функциональность с другой точки зрения.
А посредник «добавляет» функциональность, поскольку объединяет различные существующие функции для создания новой.
Возьмем следующий пример:
У вас есть система журналирования.Из этой системы журналирования вы можете войти в файл, в сокет или в базу данных.
Используя шаблон проектирования фасада, вы «спрячете» все связи существующей функциональности за одним «интерфейсом», который предоставляет фасад.
Код клиента:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Реализация может включать взаимодействие многих объектов.Но в конце концов функциональность уже существует.Вероятно, метод «отладки» реализован следующим образом:
Выполнение:
class Logger {
private LoggerImpl internalLogger;
private LoggerManager manager;
public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}
public void debug( String message ) {
this.internalLogger.debug( message );
}
}
Функционал уже существует.Фасад только скрывает это.В этом гипотетическом случае LoggerManager занимается созданием правильного средства ведения журнала, а LoggerImpl — это частный объект пакета, имеющий метод «отладки».Таким образом, Фасад не добавляет функциональности, а просто делегирует ее некоторым существующим объектам.
С другой стороны, посредник добавляет новую функциональность, комбинируя различные объекты.
Тот же код клиента:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Выполнение:
class Logger {
private java.io.PrintStream out;
private java.net.Socket client;
private java.sql.Connection dbConnection;
private String loggerName;
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}
}
public void debug( String message ) {
if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
}
В этом коде посредник — это тот, кто содержит бизнес-логику для создания соответствующего «канала» для регистрации, а также для регистрации журнала в этом канале.Посредник «создает» функциональность.
Конечно, есть более эффективные способы реализовать это с помощью полиморфизма, но суть здесь в том, чтобы показать, как медиатор «добавляет» новую функциональность, комбинируя существующую функциональность (в моем примере не очень много показано, извините), но представьте себе посредник, читайте из базы данных удаленный хост, где вести журнал, затем создает клиент и, наконец, записывает в поток печати этого клиента сообщение журнала.Таким образом, посредник будет «посредником» между различными объектами.
Наконец, фасад является структурным узором, то есть описывает состав объектов, а посредник является поведенческим, то есть описывает способ взаимодействия объектов.
Надеюсь, это поможет.
Другие советы
Я использую посредник, чтобы добавить функциональность файла журнала.
Это работает следующим образом:
- Задача A сообщает посреднику, что нужно что-то сделать.
- Посредник отправляет сообщение различным клиентским объектам.
- Объект B выполняет то, что нужно объекту A, и отправляет соответствующее сообщение обратно через посредник.
- Между тем, Obj C также отправляет оба сообщения посредником и регистрирует результаты.Таким образом, мы можем получить статистику пользователей из файлов журналов.
- Obj D также может быть средством проверки ошибок, так что, если Obj B отвечает, что запрос Obj A невозможен, Obj D может быть тем, что сообщает об этом пользователю.Ошибки теперь могут регистрироваться в файле, отличном от обычного действия, и могут использовать некоторые другие средства для поведения (звуковой сигнал и т. д.), о которых Объект A не должен особо беспокоиться.
под связанными шаблонами, гоф говорит:Фасад (185) отличается от Медиатора тем, что он абстрагирует подсистему объектов для обеспечения более удобного интерфейса.Его протокол однонаправленный;то есть объекты фасада отправляют запросы к классам подсистемы, но не наоборот.Напротив, Mediator обеспечивает совместное поведение, которое не обеспечивают или не могут обеспечить коллегиальные объекты, а протокол является многонаправленным.
Возьмем простую аналогию:
Фасад:как парковка, когда звонишь
parkingLot.Out(car1);
может быть простая цепочка работает:
{
car1.StartEngin();
attendant.charge();
car1.driverOut();
}
Посредник:как светофор.
Есть взаимодействие между светом и автомобилем,
и автомобили контролируются государством.
Я подумал, может быть, это медиатор «добавляет функциональность»
И по поводу определения:
Тип фасада: Структурный
Тип посредника: Поведенческий
Фасад больше беспокоится о компоненты были содержался в единый интерфейс,
и беспокойство посредника как набор объектов взаимодействовать.
Я думал, что различие было направленным:фасад — односторонняя связь между клиентом и фасадом;Медиатор может представлять собой двусторонний разговор, при котором сообщения передаются туда и обратно между клиентом и посредником.
В книге «Шаблоны проектирования» КЛЮЧ паттерна Медиатор описывается следующим образом:«Он (посредник) действует как центр связи для виджетов (т. е. группа взаимозависимых объектов)».
Другими словами, объект-посредник — это единственный суперобъект, который знает все остальные объекты в группе взаимодействующих объектов и то, как они должны взаимодействовать друг с другом.Все остальные объекты должны взаимодействовать с объектом-посредником, а не друг с другом.
Напротив, фасад — это «унифицированный интерфейс» для набора интерфейсов в подсистеме (для использования потребителями подсистемы), а не среди компонентов подсистемы.
Подробную информацию о шаблоне фасада вы можете найти в этом вопросе SE:
Что такое шаблон проектирования фасада?
Facade обеспечивает простой и унифицированный интерфейс для сложной системы.
Пример из реальной жизни (Cleartrip перелет+бронирование отеля) доступно в этом посте:
Что такое шаблон проектирования фасада?
Посредник шаблон:Определите объект, который инкапсулирует взаимодействие набора объектов.Медиатор способствует слабой связи, не позволяя объектам явно ссылаться друг на друга, и позволяет независимо изменять их взаимодействие.
Реальный пример топологии Mesh-сети приведен ниже в вопросе SE:
Посредник против наблюдателя Объектно-ориентированные шаблоны проектирования
Что касается вашего запроса на Mediator, это добавляет ответственности:
Фасад обеспечивает только интерфейс к существующим подсистемам..Существующие подсистемы не знают о самом классе Facade.
Медиатор знает об объектах коллег.Это обеспечивает общение между разными коллегами.В примере, который я привел в связанном вопросе, БетонМедиатор(СетьМедиатор) отправляет уведомления о регистрации и отмене регистрации одного коллеги всем остальным коллегам.
Оба налагают какую-то политику на другую группу объектов. Фасад навязывает политику сверху и Посредник навязывает политику снизу.Использование Фасад является видимым и ограничивающим, в то время как использование Посредник невидим и дает возможность.
А Фасад Шаблон используется, когда вы хотите предоставить простой и конкретный интерфейс группе объектов, имеющих сложный и общий интерфейс.
А Посредник модель также навязывает политику.Однако, хотя «Фасад» навязывал свою политику видимым и сдерживающим образом, Посредник навязывает свою политику скрытым и непринужденным образом.
Гибкая разработка программного обеспечения, принципы, шаблоны и практики Роберт К.Мартин.
