Цепь ответственности: петля или следующая?

Я реализую цепочку ответственности.Цепь ответственности: петля или следующая?

У меня есть разные политики, которые могут быть объединены в список, и у меня есть Процессор, который обрабатывает список политик. Каждая политика может обрабатывать CustomInput и может выбирать, нужно ли обрабатывать остальные политики.

interface Policy {  
    public boolean process(CustomInput input);  
} 

interface Processor {  
    public void process(List<Policy> policies, CustomInput input)  
}

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

Мой коллега предложил передать следующую Политику каждой Политике и дать им возможность позвонить (или нет) следующей (например, FilterChain).

Мой вопрос заключается в следующем:

Есть ли какие-либо преимущества я не вижу во втором растворе (проходя следующую политику в настоящее время обработки одного) над циклом по каждой политики и проверки его результат?

источник

2013-12-03 Boris

В первом случае ведущий оператор несет ответственность за применение всех политик. во втором случае каждая политика должна знать свою подполитию и может решить применить ее или нет. Это вопрос того, где вы ставите ответственность за применение политики. – njzk2

Бывают случаи, когда такой шаблон становится накладным, это также следует учитывать. В то время как CoR приятно использовать, не забудьте KISS. Есть случаи и случаи, которые следует учитывать. – EProgrammerNotFound

@Matheus, в моем случае мне это нужно (список политик происходит откуда-то другого, а код обработки не знает, что они делают, только они должны быть обработаны, прежде чем он сможет продолжить следующий шаг). – Boris

Идея прохождения следующего не имеет смысла для меня. Поэтому я хочу цепочку из:

A - B - C - D

Как C знает о D? Если это в коде для C, то любое изменение в цепочке будет огромной проблемой для реализации.

Цепочка должна либо следовать другому пути, который уже существует, как, например, респонденты, когда они просто пробуждают запросы на помощь каждому из своих родителей (пример в книге «Банда четырех»), или вам нужно постройте цепочку, поэтому в нижней части раздела в Go4 они упоминают составной шаблон как естественный соучастник.

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

Чтобы ответить на ваш основной вопрос: преимущество использования Цепочки ответственности в этом случае состоит из двух частей: 1. вы не создаете объект божества, который знает обо всех вещах, которые когда-либо могли бы достичь цели (успешное построение политики) и 2. вам не нужно вводить много уродливого кода проверки, чтобы увидеть, когда вы достигли конечной точки, потому что тот, кто ее обрабатывает, не называя своего преемника, подскажет возврат готового элемента.

источник

2013-12-03 16:04:27 Rob

Я склонен согласиться с тобой. Роб, мне не нравится тот факт, что политика должна обладать знаниями других. Я предпочел бы их легко реализовать, независимо от того, что другие. – Boris

Не могли бы вы реализовать половинное решение, которое позволяет обоим компонентам иметь контроль над деталями?

interface Policy { 
    public Policy process(CustomInput input, Policy defaultNext); 
}

process мог тогда по умолчанию возвращения defaultNext, если он не имеет свой собственный выбор.

источник

2013-12-03 15:29:53 OldCurmudgeon

Цепь ответственности: петля или следующая?

ответ

Смежные вопросы