方法級SRP與接口膨脹

我建議重構同事，他反駁了基本上引用SRP。這是情況。方法級SRP與接口膨脹

我們有一堆輔助方法，對我來說都是相關目的 - html代。可能有很多選項可以應用，我們可以稱它們爲A B和C，您可以混合搭配。

他的原始代碼對每個選項和有效組合使用了單獨的方法。我認爲這很糟糕，因爲排列可能會迅速升級失控。

public string MethodWithA() { /* ... */ } 

public string MethodWithB() { /* ... */ } 

public string MethodWithC() { /* ... */ } 

public string MethodWithAandB() { /* ... */ } 

public string MethodWithAndC() { /* ... */ } 

public string MethodWithBandC() { /* ... */ }

我們的情況並不像這種極端，但我所要求的一般情況。

我說應該有一個方法，選項應該作爲參數或枚舉標誌傳遞。

public string Method(SomeOptions flags) 
{ 
    /* minimal base processing */ 

    if (/* flag A */) 
    { 
     ModifyForA(); 
    } 

    /* etc for B and C */ 
}

他的迴應是，切換這樣的標誌意味着該方法正在做很多事情。我知道「清潔代碼」的確會說一些關於標誌或開關語句是一種氣味，但我認爲它不適用於這種情況。我認爲這個規則是關於尋找多態性的機會。無論如何，我認爲我的版本仍然在做一件事，但我想這取決於解釋。

有什麼不完全主觀的，我們可以用來解決哪種方法更好？

來源

2013-03-28 Tesserex

很難說你的例子有點過於一般，但我不喜歡這兩種方法。正如你正確地指出的那樣，第一個結果會導致組合的爆炸，但是替代方法會導致無法測試或分析的怪異方法。我更喜歡某種構建器，或者現在流行起來稱其爲流暢的界面。那麼你會有這樣的事情：

string html = htmlBuilder.WithA().WithC().Build()

來源

2013-03-28 14:20:09

方法級SRP與接口膨脹

回答

相關問題