Существует ли шаблон проектирования Java для проблемы, которую я пытаюсь решить?

Question

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

public interface CheckRule {
    boolean runRule(Product p);
}

Для каждого правила у меня может быть отдельный класс Rule, который реализует интерфейс CheckRule. После этого я могу выполнить двойной цикл для выполнения всех правил, например ::1004

for (Product p : Products) {
   for (Rule r : Rules) {
      if (! r.runRule(p) {
              // report on the broken rule
      }
   }
}

Если у меня есть сотни правил, я в итоге получаю сотни классов правил, что кажется грязным способом сделать это. Альтернативой является наличие одного класса RuleManager, который имеет отдельный метод для каждого правила, например,

public class RuleManager {

    boolean runRule1(Product p) { // rule 1 logic}

    boolean runRule2(Product p) { // rule 2 logic}

    boolean runRule3(Product p) { // rule 3 logic}

    etc...
}

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

Answer 1

Шаблон проектирования спецификаций может решить вашу проблему.

http://en.wikipedia.org/wiki/Specification_pattern

Answer 2

Посмотрите API Java Validation:

http://www.infoq.com/news/2010/03/javaee6-validation

Он поставляется с тоннами уже созданных валидаторов, которые вы можете использовать, просто добавляя свои свойства bean-компонентов с помощью определенных аннотаций (таких как @ZipCode).и @NotNull), и это позволяет вам легко объявлять пользовательские валидаторы и то, что вы хотите, чтобы они проверяли, и у вас уже есть все строительные леса.

Answer 3

шаблон? Каркасы ...

например.

• JSR303 - проверка бина -> Средство проверки гибернации
• Правила движка -> Слюни

Answer 4

Я думаю, вы обнаружите, что вы часто можете параметризовать правила, так что вам не понадобится где-то один класс на правило. Это особенно верно, если вы готовы рассмотреть возможность использования отражения.

JSR303, также известный как Java Validation API, хорош для простой проверки полей, но быстро исчерпывает себя, когда вам нужно делать более сложные вещи.

Слюни не важны, если я понимаю вариант использования - слишком тяжелый.

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

Answer 5

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

Answer 6

Кажется, лучше иметь правила как отдельные классы.Организуйте их в осмысленную иерархию пакетов, чтобы облегчить умственную нагрузку.

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