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



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



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



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



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



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

856   8  

8 ответов:

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

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

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

рассмотрим пример:

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

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

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

 Logger logger = new Logger();
 logger.initLogger("someLogger");
 logger.debug("message");

реализация может включать в себя взаимодействие многих объектов. Но в конце концов, функциональность уже существует. Вероятно, метод "debug" реализован как следует:

реализация:

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

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

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

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

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

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

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

Я надеюсь, что это помогает.

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

это работает так:

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

в разделе Связанные шаблоны,gof говорит: фасад (185) отличается от медиатора тем, что он абстрагирует подсистему объектов для обеспечения более удобного интерфейса. Его протокол является однонаправленным, то есть объекты фасада выполняют запросы классов подсистемы, но не наоборот. В отличие от этого, посредник обеспечивает совместное поведение, которое объекты-коллеги не предоставляют или не могут предоставить, а протокол является разнонаправленным.

возьмем простую аналогию:

фасад: как парковка, когда звоните

parkingLot.Out(car1);

mab быть простая цепь работает:

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

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

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

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

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


а по поводу определения:

тип фасада: структурная

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

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

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

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

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

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

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

что такое шаблон дизайна фасада?

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

реальный пример (cleartrip flight + бронирование гостиниц) доступно в этом посте:

что такое шаблон дизайна фасада?

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

реальный пример топологии ячеистой сети был представлен ниже SE вопрос:

Посредник Против Наблюдателя Объектно-Ориентированные Шаблоны Проектирования

Что касается вашего запроса на посредника добавляет ответственности:

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

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

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

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

The посредник шаблон также накладывает политику. Однако, в то время как фасад навязывал свою политику видимым и сдерживающим образом,посредник навязывает свою политику скрытым и неограниченным образом.

гибкая разработка программного обеспечения, принципы, шаблоны и практики Роберт С. Мартин.

Comments

    Ничего не найдено.