복합 전략 패턴 - java -이 코드는 얼마나 나쁜가요?

Question

이 질문은 이전 게시물의 일부입니다. Visitor pattern implementation in java- How does this look?

내 코드를 리팩터링하는 동안 약간 혼란스러워졌습니다. 이전 방문에서 설명한 방문자 패턴을 복합 전략 패턴으로 변환하려고합니다. 나는 이런 식으로 뭔가를 시도하고있다 : 이제

public interface Rule { 
    public List<ValidatonError> check(Validatable validatable); 
} 

, 나는 다음과 같은 규칙을 정의 할 :

public class ValidCountryRule { 
    public List<ValidationError> check(Validatable validatable) { 
    // invokeDAO and do something, if violation met 
    // add to a list of ValidationErrors. 
    // return the list. 
    } 
} 

을 지금, 나는이 두 가지 유형을 가질 수 것은 검증 될 객체. 이 두 가지는 완전히 다른 것일 수 있습니다. Validatable 인 상점과 인 Schedule이 있다고 가정 해보십시오. 나는이 같을 것이다 복합을 작성하면 이제 :

class Validator implements Rule { 
    private List<Rule> tests = new ArrayList<Rule>(); 

    public void addRule(Rule rule) { 
    tests.add(rule); 
    } 

    public List<ValidationError> check(Visitable visitable) { 
    List<ValidationError> list = new ArrayList<ValidationError>(); 
    for(Rule rule : tests) { 
     list.addAll(rule.check(visitable); 
    } 
    } 

    public Validator(ValidatorType type) { 
    this.tests = type.getRules(); 
    } 
} 

나는 ... 검사의 설정 무엇을 정의하는 enum가 어디로 가야

public Enum ValidatorType { 
    public abstract List<Rule> getRules(); 
    STORE_VALIDATOR { 
    public List<Rule> getRules() { 
     List<Rule> rules = new ArrayList<Rule>(); 
     rules.add(new ValidCountryRule()); 
     rules.add(new ValidXYZRule()); 
    } 

    // more validators 
} 

을 정의하는 것 그리고 마지막으로, 내가 사용하는 것이 그것은 다음과 같습니다 :

Validator validator = new Validator(ValidatorType.STORE_VALIDATOR); 
for (Store store : stores) { 
    validator.check(store); 
} 

나는 내 디자인에 결함이 있다는 이상한 느낌이 있습니다. 내 Rule 인터페이스가 Validatable을 기대하고 있다는 생각을 좋아하지 않습니다. 이걸 어떻게 향상 시킬지 제안 해 주시겠습니까?

감사합니다.

Answer 1

유효성 검사 프레임 워크 형식을 안전하게 만들기 위해 Validatable를 일반 형식 매개 변수 T로 바꿉니다.

public interface ValidationStrategy<T> { 
    public List<Rule<? super T>> getRules(); 
} 

을 우리는 그래서 우리는 (개 가정 개가 검사기에 동물에 대한 규칙을 추가 할 수 있습니다에 의해 제한 규칙을 다루고있는 '슈퍼 T? "

public interface Rule<T> { 
    public List<ValidationError> check(T value); 
} 

의가 인터페이스 ValidationStrategy 우리의 프레임 워크를 확장 할 수

Animal을 확장). 유효성 검사기는 이제 다음과 같습니다 여러 개 검증 전략을 제공하는 열거를

public class DogValidationStrategy implements ValidationStrategy<Dog> { 
    public List<Rule<? super Dog>> getRules() { 
     List<Rule<? super Dog>> rules = new ArrayList<Rule<? super Dog>>(); 
     rules.add(new Rule<Dog>() { 
      public List<ValidationError> check(Dog dog) { 
       // dog check... 
       return Collections.emptyList(); 
      } 
     }); 
     rules.add(new Rule<Animal>() { 
      public List<ValidationError> check(Animal animal) { 
       // animal check... 
       return Collections.emptyList(); 
      } 
     }); 
     return rules; 
    } 
} 

또는 샘플처럼, 우리는 할 수 있습니다 :

public class Validator<T> implements Rule<T> { 
    private List<Rule<? super T>> tests = new ArrayList<Rule<? super T>>(); 

    public Validator(ValidationStrategy<T> type) { 
     this.tests = type.getRules(); 
    } 

    public void addRule(Rule<? super T> rule) { 
     tests.add(rule); 
    } 

    public List<ValidationError> check(T value) { 
     List<ValidationError> list = new ArrayList<ValidationError>(); 
     for (Rule<? super T> rule : tests) { 
      list.addAll(rule.check(value)); 
     } 
     return list; 
    } 
} 

이제 우리는이 같은 샘플 DogValidationStrategy을 구현할 수 있습니다

public enum DogValidationType implements ValidationStrategy<Dog> { 
    STRATEGY_1 { 
     public List<Rule<? super Dog>> getRules() { 
      // answer rules... 
     } 
    }, 
    // more dog validation strategies 
} 

Answer 2

처음 디자인 패턴에 대해 배울 때, 나는 계속 사용할 패턴을 찾고있었습니다. 나는 조숙 한 "패턴 화"가 조숙 한 최적화와 같다고 배웠습니다. 먼저, 그것을 직선적 인 방식으로 시도한 다음, 어떤 문제가 발생했는지 확인하십시오.

최소한의 인터페이스와 하위 클래스로 디자인 해보십시오. 그런 다음 분명한 중복을 위해 적절한 패턴을 적용하십시오. 이 코드와 이전 게시물에서 여러분이 코드를 너무 많이 만들었다는 인상을받습니다.