Question

我建议对同事进行重构，他反驳说基本上引用了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 */
}

他的回答是，切换这样的标志意味着该方法正在做多件事。我知道“清洁代码”确实说过标志或开关语句是一种气味，但我不认为它适用于这种情况。我认为这个规则是关于寻找多态性的机会。无论如何，我认为我的版本仍在做一件事，但我想这取决于解释。

我们可以用什么不完全主观的方法来解决哪种方法更好？

Answer 1

很难说你的例子有点过于通用，但我不喜欢这两种方法。正如你所正确注意到的那样，第一个导致组合爆炸，但替代方案将导致一种无法测试或分析的怪异方法。我更喜欢某种建设者，或者现在很流行称它为流畅的界面。然后你会有类似的东西：

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

方法级SRP与接口膨胀

1 个答案: