Будет ли это все еще рассматриваться как схема цепочки ответственности? - PullRequest
Новая
       35

Будет ли это все еще рассматриваться как схема цепочки ответственности?

0 голосов
/ 28 июня 2011

Я уже давно использую шаблон проектирования и называю / называю его « Шаблон цепочки ответственности », но теперь я понимаю, что есть различия, и это может и не произойти подойдет для этого. Итак, мой вопрос 1: «Является ли следующий образец этой модели, или его следует назвать как-нибудь еще?», И 2, «есть ли причина, по которой я предпочитаю традиционный способ?».

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

interface FooBar{
    boolean isFooBar( Object o );
}

Обычно это классы поиска, фильтрации или обработки; обычно что-то вроде Comparator . Способ реализации обычно является функциональным (то есть без побочных эффектов). В конце концов, я создаю реализацию интерфейса, которая выглядит следующим образом: 

class FooBarChain implements FooBar{
    FooBar[] foobars;

    FooBarChain( FooBar... fubars ){
         foobars = fubars;
    }

    boolean isFooBar( Object o ){
         for( FooBar f : foobars )
             if(  f.isFooBar( o )  )
                 return true;

         return false;
    }
}

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

До сих пор я обычно называл это шаблоном "Цепочка ответственности", рассматривая вопрос наследования от базового класса как деталь реализации. Однако сегодня я осознал важное различие: объекты вдоль цепи не могут прерывать остальную часть цепи. Реализация не может сказать «это ложно, и я могу гарантировать, что оно будет ложным для любого условия» (примечание: короткое замыкание только на true).

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

Ответы [ 2 ]

2 голосов
/ 29 июня 2011

Я бы не назвал эту цепочку цепочки ответственности.

В цепочке ответственности «короткое замыкание» примерно такое: «Я справлюсь с этим, поэтому следующий парень в цепочке недолжны ", а не быть возвращаемым значением любого рода.Для каждого объекта в цепочке нормально знать, кто следующий в цепочке, и при необходимости передавать управление этому следующему объекту.Обычно они делают что-то вместо того, чтобы возвращать значение.

Пример, который вы представили, вполне оправдан, хотя я не уверен, что это именованный шаблон.Мне не очень ясно сейчас о других вариантах, которые вы описываете.

1 голос
/ 28 июня 2011

То, что у вас есть, является цепочкой ответственности, но вы можете создать «чистую» цепочку ответственности, добавив несколько небольших изменений.

Вы можете создать перечисление, которое будет представлять 3 различных результата, которые вы ожидаете от этой функции. 

 public enum Validity{
     Invalid,
     Indeterminate,
     Valid
 }

Вы можете изменить интерфейс на цепочку, например: 

 public interface ChainFooBar{
     public boolean isFooBar(Object o);
     public Validity checkFooBar(Object o);
 }

Большинство ваших FooBar s должны были бы реализовать метод, подобный этому: 

public abstract class AbstractFooBar implements FooBar{
    public Validity checkFooBar(Object o){
        return this.isFooBar(o) ? Validity.Valid : Validity.Indeterminate;
    }
}

Затем вы можете изменить свою цепочку, чтобы проверить любой из определенных ответов. 

public class FooBarChain implements FooBar{
    private FooBar[] fooBars;

    public FooBarChain(FooBar... fooBars){
        this.fooBars = fooBars;
    }

    public Validity isFooBar(Object o){
        for(FooBar fooBar : this.fooBars){
            Validity validity = fooBar.checkFooBar(o);
            if(validity != Validity.Indeterminate){
                return validity == Validity.Valid;
            }
        }
        return false;
    }
}
...