何时会违反SRP（单一职责原则）？

Question

SRP(PDF版本；HTML版本)表明：

一个类的改变原因不应该超过一个

当你看Outlook，日历事件窗口时，它有“保存并关闭”按钮。

所以当保存或关闭的功能发生变化时，该按钮应该改变。这显然违反了SRP。

这个功能既节省时间又方便，因为这是大多数用户保存日历约会时所期望的。

但现在，我的问题是，在哪些情况下你违反SRP，除了需要在Outlook中使用该功能时？

- Sung Meister

---

糟糕的例子。按钮代码中的函数具有两个动作的_sequence_：“Save()”和“Close()”。这并不违反任何规定。任何函数都可以是序列、迭代或选择。 - Daniel Daranas

如果实现该按钮，代码将为 if(Save()) Close();。如果其中任何一个更改，需要更改什么？ - Damien_The_Unbeliever

@Daniel和Damien：如果Outlook有一个“SaveAndClose()”方法，既可以保存又可以关闭，那该多好啊；如果没有“Save()”或“Close()”这样的函数会怎么样呢？ - dance2die

@Daniel 我对这个问题的假设是Outlook可能有一个类似于"SaveAndClose()"的函数，它可以在不使用"两个不同的抽象"的情况下完成两个操作。 - dance2die

这是否是SRP违规的一个例子？我需要添加一个新产品并返回新产品列表。我将我的添加和获取列表方法合并为一个函数，以便我只需对服务器进行一次调用。我的做法正确吗？ - Ken

Answer 1

单一职责原则(SRP)不适用于用户界面(UI)。请记住，即使按钮被称为“保存并关闭”，也可以有两种不同的方法或类型来处理保存和关闭功能。按钮只是将这两个不同的功能组合在一起。

如果您感觉需要违反SRP，则需要重新评估您的方法。任何SRP违规都可以重构为一种新的方法或类型，通过组合这两个部分来暴露复合功能。

- Andrew Hare

---

实际上，它也适用于用户界面(UI)。但是这个例子展示了一些在幕后由某些控件(Control)和/或模型(Model)实现的UI问题。该问题混淆了UI变化和模型/控件变化；这并不太有意义——每个都是根据SRP构建的。 - S.Lott

是的，我同意你的观点。在重新阅读我的第一句话后，我意识到我实际上是错误的。我想我会把它留在那里，因为如果我删除它，你的评论就没有太多意义了。我感谢你敏锐的评论，我不希望它出现在错误的背景下。 :) - Andrew Hare

我认为“从不”正是合适的词。通常情况下，“从不”的使用很夸张，但在这种情况下并非如此。“单一职责原则”的任何违规都可以通过最小的努力进行重构以消除违规。我想我想要表达的是“是的”。 :) - Andrew Hare

@标记为答案：谢谢Andrew。你的解释在回答和评论中都很清晰。 - dance2die

我承认违反了SRP原则，是时候进行重构了！ - dance2die