Блог

Следующий поддельный пример-это класс, который облегчает процесс опроса, сохраняет результаты и сохраняет их в базе данных. Я понимаю, что это будет рассматриваться как шаблон посредника, поскольку он облегчает связь между объектами, которые в противном случае были бы связаны без него. Является ли это точным или существует другая модель, которая лучше объясняет такое поведение? Спасибо!

 public class StatusPoller
{
    public void Poll()
    {
        foreach(User user in users)
        {
           string accessToken = oAuthClient.Authenticate(user);   // Authenticate
           List<status> statuses = pollingClient.PollStatus(accessToken);   // Poll for status
           Store(statuses);   // Store statuses in DB
        }

        Message.Dispatch(5)  // Dispatch a new message on a delay
    }
}
 

Вид,

проблема, которую решает шаблон посредника, заключается в следующем

We want to design reusable components, but dependencies between the potentially reusable pieces demonstrates the "spaghetti code" phenomenon (trying to scoop a single serving results in an "all or nothing clump").

итак, когда StatusPoller вводится и обрабатываются все его зависимости, такие как oAuthClient pollingClient и dbContext (это, вероятно, в Store методе)

мы снижаем сложность взаимодействия между всеми этими объектами.

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

таким образом, в основном вы StatusPoller выступаете в качестве конкретного посредника

Это не какой-то конкретный шаблон дизайна, и это совершенно нормально. Это всего лишь метод. Не каждый метод должен быть или должен быть шаблоном проектирования. Более конкретно, преобразование A --> B в A --> C --> B не является Посредником. Если бы это было так, то уровень обслуживания каждого веб-приложения был бы посредником между контроллерами и DAO. Посредник преобразует паутину, подобную этой,

            A —→ C
            ↘ ↙↗ ↖↘
             D ←—→ E
              ↖ B ↗
 

в такой дизайн, как этот,

          A        B        C
          ↘       ↓      ↙↗
           M e d i a t o r
         ↙↗       ↑↓
        D         E
 

где ни один из объектов не разговаривает друг с другом напрямую, и все (двустороннее) общение происходит через Посредника.

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

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