Использование FactoryMethod картины

Question

У меня есть две отдельные сущности:

public enum Rule implements Validatable, StringRepresentable{ 
    //... 
} 

и

public inteface Filter extends Validatable, StringRepresentable{ 
    //... 
} 

Где

public inteface Validatable{ 
    public GenericValidator getValidator(); 
} 

и

public interface StringRepresentable{ 
    public String getStringRepresentation(); 
} 

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

Я не понимаю, когда это лучше создать класс как

public class ValidatorFactory{ 
    public Validator getRuleValidator(Rule r){ ... } 
    public Validator getFilterValidator(Filter f){ ... } 
} 

вместо реализации интерфейса Validatable как я показано ранее.

Не может кто-нибудь объяснить, как я могу принять правильное решение? Какие потенциальные обстоятельства требуют применения FactoryMethod плохого решения, и когда это будет действительно хорошо?

UPD:

public interface Validator{ 
    public ErrorCode validate(); 
} 

public abstract class GenericValidator implements Validator{ 
    //... 
} 

ErrorCode класс инкапсулирует результат проверки (null если valiadtion как будет завершен succsfully).

Answer 1

Единой Ответственность Принцип

Строительство валидатора является один ответственностью, фильтр или правило, вероятно, носит еще один. Это означает, что мы должны разделить его, и обычно мы делаем это, инкапсулируя логику создания экземпляра в шаблон Factory.

Также обратите внимание, что реализация Validatable означает ValidatorFactory.Мой ответ был бы - объединить оба решения:

public class FilterImpl implements Filter { 
    private final Validator validator; 

    public FilterImpl(Validator validator) { 
     this.validator = validator; 
    } 

    @Override 
    public getValidator() { 
     return this.validator; 
    } 

    //... 
} 

public class FilterFactory { 
    private final ValidatorFactory validatorFactory = new ValidatorFactory(); 

    public Filter createFilter() { 
     return new FilterImpl(valdatorFactory.createFilterValidator()); 
    } 
} 

Это называется Dependency Injection. интерфейс

Answer 2

Я использую этот шаблон в двух основных случаях:

A) Строительство объекта не тривиальное - Я не доверяю пользователям по API, чтобы сделать это правильно

B) Есть больше реализаций, и я хочу сам выбрать правильный.

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

Всегда стремиться к простоте и простоте использования для пользователя. Задайте себе следующие вопросы:

1. Является ли API понятным?
2. Является ли API легким/забавным в использовании?
3. Является ли это надежным? (Я должен попытаться довольно трудно злоупотреблять им)

Answer 3

валидатор может выглядеть следующим образом:

public interface Validator { 
    public int validate(); 
} 

интерфейс фильтра может выглядеть следующим образом:

public interface Filter { 
    public String getParameters(); // some related methods.. 
    public int currentLength(); 
    .... 
} 

Правило интерфейса:

public interface Rule { 
    public String getRule(); 
} 

FilterValidator может выглядеть следующим образом:

public class FilterValidator implements Validator{ 

private Filter f; 

public FilterValidator(Filter f){ 
    this.f = f; 
} 

@Override 
public int validate() { 
    // validate f and return errorcode 
    String params = f.getParameters(); 
    int strLength = f.currentLength(); 
    ..... 

    return 0; 
} 

} 

Создание фабрики лучше скрыть внутреннюю логику валидаторов.

public class ValidatorFactory { 

public Validator getRuleValidator(Rule r){ 
    return null; 
} 

public Validator getFilterValidator(Filter f){ 
    FilterValidator fv = new FilterValidator(f); 
    return fv; 
} 
} 

Теперь клиент будет вызывать этот factoy так:

public class ClientDemo { 

    private class MyFilter implements Filter{ 

    private String filterInput; 
    public MyFilter(String input){ 
     this.filterInput = input; 
    } 

    @Override 
    public String getParameters() { 
     return null; 
    } 

    @Override 
    public int currentLength() { 
     return this.filterInput.length(); 
    } 

} 

    public void testValidators(){ 

     ValidatorFactory factory = new ValidatorFactory(); 
     Validator v = factory.getFilterValidator(new MyFilter("filter string goes here...")); 
     v.validate(); 
    } 
} 
} 

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