Какой дизайн лучше: универсальный застройщик или несколько конкретных методов? - PullRequest
2 голосов
/ 12 июля 2010

Мне нужно создать службу уведомлений по электронной почте (в рамках более крупного проекта).

Он будет использоваться для отправки уведомлений нескольких типов на основе html-шаблонов.

Я могу создать его двумя способами:

  1. Первый способ основан на модели строителя. Он универсален (как мне кажется) и может справиться со всеми необходимыми случаями. Но это не очень удобно для тех, кто будет его использовать. Типичное использование будет выглядеть так:

    messageBuilder
       .put("name", "John Doe")
       .put("company", companyObj)
       .processPattern(pattern)
       .send(addresses, subject);
    
  2. Второй способ - реализовать все случаи в явном виде. Это означает, что код использования (показанный ниже) будет настолько простым, насколько это возможно, но нам придется изменять API (добавлять новые методы) каждый раз, когда нам нужно обработать любой новый случай.

    messageSender.sendPersonExpenceNotification(addresses, "John Doe", company); 
    

Какой из них лучше? Зачем? (язык Java, если это имеет значение)

Спасибо!

Ответы [ 3 ]

2 голосов
/ 12 июля 2010

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

0 голосов
/ 12 июля 2010

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

Реализация его довольно обыденна, учитывая, что это просто вопрос правильного выбора имен ваших методов.все библиотеки FEST * .

0 голосов
/ 12 июля 2010

Effective Java 2nd Edition, Item 2: Рассмотрим конструктор, когда сталкиваемся со многими параметрами конструктора .

Шаблон компоновщика более читабелен, тем более что у вас потенциально гораздо больше параметров. Тем не менее, как правило, для компоновщика характерны специальные методы setName, setCompany и т. Д. Таким образом, вы также можете обеспечить безопасность типов, например, setSomeBoolean(boolean), setSomeInt(int) и т. Д.

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

Похожие вопросы

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...