2015-03-18 5 views
0

Я рефакторинг фрагмента кода, который имеет огромный список ветвей if/else.
Я использую шаблон стратегии, как предложено here, и создали кучу классов, реализующих функциональность внутри ветвей if.
Работая над этим я обнаружил, что есть несколько случаев, что код делает некоторые «лишнюю» работу, прежде чем на самом деле делать реальную работу, так что теперь я хочу, чтобы сделать Sanest проектного решения:
1) Есть что-то следующим образом:Наследование против крючков в абстрактных классах подход к дизайну

public abstract class Processor { 
    private abstract void mainProcess(Object o); 
    protected void preProcess(Object o) {} 
    public void process(Object o) { 
     preProcess(o); 
     mainProcess(o); 
    } 
} 

И очень немногие классы на самом деле будут переопределять и preProcess с определенной логикой, а для остальных это просто «пустой» крючок.

2) Есть что-то вроде:

public interface Processor { 
    public void process(Object o); 
} 

    public class XProcessor implements Processor { 
     @Override 
     public void process(Object o) { 
      //code here 
     } 
    } 

    public class SpecialCaseProcessor extends XProcessor { 
     private void preProcess(Object o) { 
     //code here 
     } 

     @Override 
     public void process(Object o) { 
      preProcess(o); 
      super.process(o); 
     } 
    } 

Честно говоря, я вроде как (1), но мне не нравится, что только, например, 5 из 30 классов фактически реализуют препроцесс.

В (2) Я избегаю пустые крючки но я должен был бы путь в моем «конструктор/завод», чтобы различать между конкретными протяженных подклассов

Что такое здравомыслящий/самый читаемый подход?

+0

@GriffeyDog: Вы правы. Я исправил OP, чтобы показать свою идею. – Jim

+2

Почему «preProcess» и 'mainProcess' вообще существуют в этом сценарии, если все, что вы делаете с ними, вызывает их непосредственно после другого из' process'? –

+0

@PhilippWendler: В моем сознании это похоже на «принуждение» рецепта. В некоторых случаях мне нужен препроцесс до фактической основной обработки, а в других - не – Jim

ответ

0

Я думаю, что вы можете иметь что-то вроде этого -

1) Processor интерфейс

2) AbstractProcessor абстрактный класс, который реализует Processor и имеет preProcess абстрактный метод.

3) Пусть ваши неспецифические корпусные процессоры реализуют Processor, а специальные корпусные процессоры расширяют класс AbstractProcessor.

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

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