2016-07-05 10 views
1

の条件部分をリファクタリングするためのアプローチの改善:上記のコードは、新たな条件として成長する可能性が私は下記のようなコードの特定の部分をリファクタリングしようとしていたコード

Method(URL link) 
{ 
    if(ConditionA(link)) 
    { 
     MehodA(link); 
    }else if(ConditionB(link)) 
    { 
     MehodB(link); 
    }else if(ConditionC(link)) 
    { 
     MehodC(link); 
    }else if(ConditionD(link)) 
    { 
     MehodD(link); 
    } 
} 

元のコード将来来るかもしれない。

をリファクタリング後::リファクタリング後、私は次のように初期の複雑さを軽減し、したがって、単一の責任を重視複数のクラスごとにコードを分割することができる午前

METHOD(URL link) 
{ 
    ConditionalHandlerClass obj = new ConditionalHandlerClass(link); 
    ConditionalHandlerClass.HandleLinkProcessing(); 
} 

Class ConditionalHandlerClass 
{ 
    URL link; 
    IConditionalProcess process; 

    public ConditionalHandlerClass(URL _link) 
    { 
    link = _link; 
    } 

    public void HandleLinkProcessing() 
    { 
    if(ConditionA(link)) 
     { 
      process = new ProcessA(link); 
     }else if(ConditionB(link)) 
     { 
      process = new ProcessB(link); 
     }else if(ConditionC(link)) 
     { 
     process = new ProcessC(link); 
     }else if(ConditionD(link)) 
     { 
     process = new ProcessD(link); 
     } 
    process.Handle(); 
    } 
} 

interface IConditionalProcess 
{ 
    void handle(); 
} 


class ProcessA() : IConditionalProcess 
{ 
    void handle() 
    { 
    // Business Logic here 
    } 
} 

class ProcessB() : IConditionalProcess 
{ 
    void handle() 
    { 
    // Business Logic here 
    } 
} 

class ProcessC() : IConditionalProcess 
{ 
    void handle() 
    { 
    // Business Logic here 
    } 
} 

class ProcessD() : IConditionalProcess 
{ 
    void handle() 
    { 
    // Business Logic here 
    } 
} 

しかし、私はしているHandleLinkProcessing()メソッドを参照してください新しい条件が追加され続けると、ConditionalHandlerClassクラスは依然として増加し続けるでしょう。

ConditionE()およびMethodE()呼び出しの新しいフローの追加時に、ConditionalHandlerClassなどのクラスを変更しないように、この実装をより良くする方法を提案できますか。したがって、新しい条件が追加されても、クラスの複雑さを一度に減らすことができます。

私はこのコードを目的cに書いています。

+0

http://stackoverflow.com/questions/38184481/business-logic-validation-patterns-advices –

答えて

関連する問題