Фасад против посредника

Я исследовал разницу между этими двумя шаблонами.

Я понимаю, что фасад инкапсулирует доступ к подсистеме, а медиатор инкапсулирует взаимодействия между компонентами.

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

В настоящее время я использую фасад для инкапсуляции способа извлечения информации о конфигурации, например. App.Config, пользовательские настройки, хранящиеся в SQL, информация о сборке и т.д., И посредник для навигации между различными формами окон.

Однако большинство сайтов указывают, что медиатор "добавляет функциональность". Что они подразумевают под этим? Как медиатор добавляет функциональность?

ОТВЕТЫ

Ответ 1

... большинство сайтов указывают, что медиатор "добавляет функциональность"...

фасад предоставляет только существующие функции с другой точки зрения.

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

Возьмем следующий пример:

У вас есть система ведения журнала. Из этой системы регистрации вы можете либо войти в файл, либо в сокет, либо в базу данных.

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

Клиентский код:

 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 - это закрытый объект пакета, который имеет метод "отладки". Таким образом, Facade не добавляет функциональности, которую он просто делегирует некоторым существующим объектам.

С другой стороны, медиатор добавляет новую функциональность, комбинируя разные объекты.

Тот же код клиента:

 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();
               }
      }
 }

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

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

Наконец, фасад является структурным шаблоном, то есть описывает состав объектов, а посредник - поведенческий, то есть описывает способ объекты взаимодействуют.

Надеюсь, это поможет.

Ответ 2

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

Он работает следующим образом:

  • Obj A сообщает посреднику, что ему нужно что-то сделать.
  • Медиатор отправляет сообщение различным клиентским объектам.
  • Obj B выполняет задачу Obj A и отправляет соответствующее сообщение через посредника.
  • Между тем, Obj C также отправляет оба сообщения посредником и регистрирует результаты. Таким образом, мы можем получить статистику пользователя из файлов журнала.
  • Obj D также может быть средством проверки ошибок, так что если Obj B ответит, что Obj Запрос невозможен, Obj D может быть тем, что сообщает об этом пользователю. Ошибки теперь могут регистрироваться в другом файле, чем обычная активность, и могут использовать некоторые другие способы вести себя (звучать, что угодно), что Obj A не должен действительно касаться себя.

Ответ 3

под соответствующими шаблонами gof говорит: Facade (185) отличается от Mediator тем, что он абстрагирует подсистему объектов, чтобы обеспечить более удобный интерфейс. Его протокол является однонаправленным; то есть объекты Facade обрабатывают запросы классов подсистем, а не наоборот. Напротив, Медиатор позволяет совместное поведение, которое объекты коллеги не предоставляют или не могут предоставить, а протокол является многонаправленным.

Ответ 4

Простая аналогия:

Фасад: как автостоянка, при вызове

parkingLot.Out(car1);

mab - простая цепочка работает:

{
  car1.StartEngin();      
  attendant.charge();
  car1.driverOut();
}

Посредник: как светофор.

Есть взаимодействия между светом и автомобилем,

и автомобили контролируются этим состоянием.

Я, возможно, это посредник "добавляет функциональность

И об определении:

Тип фасада: Структурный

Тип посредника: Поведенческий

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

и медиатор относятся к как набор объектов взаимодействует.

Ответ 5

Я думал, что различие было направленным: фасад - это односторонняя связь между клиентом и фасадом; посредник может быть двухсторонним разговором, при этом сообщения текут между клиентом и посредником.

Ответ 6

Из книги "Образцы рисунков" КЛЮЧ для шаблона посредника описывается следующим образом: "Он (посредник) выступает в качестве концентратора связи для виджетов (т.е." Группы "взаимозависимых объектов).

Другими словами, объект-посредник является единственным суперобъектом, который знает все остальные объекты в группе взаимодействующих объектов и как они должны взаимодействовать друг с другом. Все другие объекты должны взаимодействовать с объектом-посредником, а не друг с другом.

Напротив, фасад представляет собой "унифицированный интерфейс" для набора интерфейсов в подсистеме - для использования потребителями подсистемы - не среди компонентов подсистемы.

Ответ 7

Информацию о шаблоне фасада можно найти в этом вопросе SE:

Что такое шаблон оформления фасада?

Facade обеспечивает простой и унифицированный интерфейс для сложной системы.

Пример реального мира (clearart + бронирование отелей) доступен в этом сообщении:

Что такое шаблон оформления фасада?

Mediator pattern: определить объект, который инкапсулирует, как взаимодействует набор объектов. Посредник способствует свободному соединению, не допуская прямого доступа объектов друг к другу, и позволяет вам независимо изменять их взаимодействие.

Пример реальной топологии сети Mesh в реальном мире приведен ниже в вопросе SE:

Объектно-ориентированные шаблоны проектирования медиатора Vs Observer

Относительно вашего запроса на Mediator добавляется ответственность:

  • Фасад обеспечивает только интерфейс к существующим подсистемам. Существующие подсистемы не знают о самом классе Facade.

  • Посредник знает об объектах коллег. Это позволяет общаться между разными коллегами. В примере, который я привел в связанном вопросе, ConcreteMediator (NetworkMediator) отправляет уведомления о регистрации и отмене регистрации одного коллеги всем другим коллегам.