问题标签 [solid-principles]

罗伯特·马丁说：“改变班级的理由不应该不止一个”。

让我们考虑绑定到视图的 ViewModel 类。ViewModel 有可能（甚至很可能）由彼此并不真正相关的属性组成。对于小视图，ViewModel 可能是相当一致的，但是当应用程序变得更加复杂时，ViewModel 会暴露数据，这些数据会因不同和不相关的原因而发生变化。

在 ViewModel 类的情况下，我们是否应该担心 SRP 原则？

我制作了以下代码示例来学习如何使用泛型方法签名。

为了同时获得 Customer 和 Employee 的Display() 方法，我实际上开始用 Person 抽象类替换我的IPerson接口。

但后来我停了下来，想起了一个播客，其中 Bob 叔叔告诉 Scott Hanselman单一职责原则，其中你应该有很多小类，每个类都做一件特定的事情，即 Customer 类不应该有Print()和Save ()和CalculateSalary()方法，但您应该有一个CustomerPrinter 类 和一个CustomerSaver 类和一个CustomerSalaryCalculator 类。

这似乎是一种奇怪的编程方式。然而，摆脱我的界面也感觉不对（因为有很多 IoC 容器和 DI 示例固有地使用它们）所以我决定尝试单一责任原则。

因此，以下代码与我过去编写的代码不同（我会使用 Display() 方法创建一个抽象类并摆脱接口），但基于我听说的关于解耦和 SOLID 原则的内容，这个新的编码方式（接口和 PersonDisplayer 类） 我认为这是正确的方法。

我想听听其他人在这个问题上是否有同样的想法，或者是否经历过这个问题的积极或消极影响（例如，数量庞大的班级，每个班级都在做一件特定的事情，等等）。

对于这个问题的主观性，我深表歉意，但我有点卡住了，我希望得到以前必须处理过这个问题的任何人的一些指导和建议：

我有（现在变成了）一个用 C# 2.0 编写的非常大的 RESTful API 项目，而且我的一些类变得很可怕。我的主要 API 类就是一个例子——有几十个成员和方法（可能接近数百个）。正如您可以想象的那样，它正在成为一场小噩梦，不仅要维护此代码，甚至只是导航代码都已成为一件苦差事。

我对 SOLID 原则相当陌生，而且我是设计模式的忠实粉丝（但我仍处于可以实现它们的阶段，但还不足以知道何时使用它们——在不那么明显的情况下） .

我需要将我的班级缩小规模，但我不知道如何最好地做到这一点。我的 StackOverflow 同事能否建议他们采用现有代码单体并将它们缩小到大小的方法？

我喜欢“为接口编程”的想法，并避免使用“new”关键字。

但是，当我有两个具有相同接口但设置根本不同的类时，我该怎么办。在不详细介绍我的特定代码的情况下，我有一个带有方法“DoStuff”的接口。两个类实现了这个接口。一个非常简单，不需要初始化。另一个有五个不同的变量需要设置。当它们组合在一起时，当调用 DoStuff 时，它们允许类以数百万种方式工作。

那么我什么时候“新”这些课程呢？我虽然关于使用工厂，但我认为它们不适合这种情况，因为设置存在巨大差异。（顺便说一句：实际上有大约十个不同的类使用该接口，每个类都允许形成复杂管道的一部分，并且每个类都有不同的配置要求）。

牛仔程序员需要一些 SO-veterans 的帮助：

我有一个给定的应用程序，它使用从文件中读取的书目（实际上，它可以是不同的文件，但我们假设只有一个文件）。

我构建了一个新的应用程序，它应该以与应用程序相同的方式使用参考书目，所以我复制了相应的类。

几天后，我开始运行 %-| ...

问题如下：

在 Bibliography 类中，有代码可以读取、编写和保存参考书目。当有一个类可以阅读参考书目和一个保存所有值的容器类时，我的工作会容易得多。我不想编写或编辑参考书目，只需将其读入并保留值。

那么我的想法是否正确，最好将参考书目类划分为 BibliographyReader、BibliographyWriter 和 Bibliography(Container) 类？

PS：有人可以创建一个标签“cowboy coder”、“cowboy coding”或类似的东西吗？我真的很想念这个标签；）

在下面的视频中，作者采用了一个现有的类并将单一责任原则分配给它。他参加了一个打印类，该类的任务是访问数据、格式化和打印报告。他将每个方法分解为自己的类，因此他创建了一个 DataAccess 类来处理数据访问，他创建了一个 ReportFormatter 类来处理报表的格式，他创建了一个 ReportPrinter 类来处理报表的打印。原来的 Report 类只剩下一个方法 Print()，它调用 ReportPrinter 的类方法 Print。DataAccess 和 ReportFormatter 似乎有责任，但 ReportPrinter 依赖于 DataAcess 和 ReportFormatter，所以这不会破坏 SRP 还是我误解了它？

是否有特定的设计模式描述了提供非抽象默认实现的场景，该实现使用空的 NO-OP 实现实现接口上的所有或部分方法。这样做的目的是减轻子类实现它们自己可能不需要/使用的方法的负担：

我已经看到这种模式多次使用，包括SAX 框架中的 Java 的 DefaultHandler和MouseAdapter。在某些情况下，此类类被命名为适配器，但我的印象是适配器模式在两个不同的接口之间进行转换。

鉴于在这些情况下，只有一个已声明的接口被转换为该接口的未定义子集——我不清楚这如何符合适配器模式的精神。

此外，鉴于某些方法可能具有实现，并且 NullObject 传统上是单例，我也不太明白这如何遵守NullObject 模式。

我有在后台线程中运行的代码，需要定期检查用户是否要中止工作。

问题是如何在大部分 SOLID 环境中实现这一点。

• ICancel我注入每个类的接口。
• 某处的公共静态成员

非常量静态似乎总是迟早会产生问题。另一方面，“标准”注入的数量正在稳步增长（ILogger、IPProgressReporter 等），因此像取消这样的简单操作可能是使用静态的不错选择。

还有其他/更好的方法吗？有人有经验分享吗？

我正在使用 WPF 和 C#，但问题很笼统。

这是一个例子：

我正在寻找一些违反单一职责原则的代码的好例子。不要给我看鲍勃叔叔的书或网站中的任何例子，因为这些例子遍布互联网，就像这个：

我在一个非常重视单一职责原则的项目中。我们有很多小班，事情很简单。然而，我们有一个贫乏的领域模型——在我们的任何模型类中都没有行为，它们只是属性包。这不是对我们设计的抱怨——它实际上似乎工作得很好

在设计评审期间，每当向系统添加新行为时，都会引入 SRP，因此新行为通常会在新类中结束。这使事情很容易进行单元测试，但有时我会感到困惑，因为感觉就像将行为从相关的地方拉出来。

我正在努力提高我对如何正确应用 SRP 的理解。在我看来，SRP 反对将共享相同上下文的业务建模行为添加到一个对象，因为该对象不可避免地最终要么做不止一件相关的事情，要么做一件事但知道改变形状的多个业务规则其输出。

如果是这样，那么感觉最终结果是一个贫血域模型，这在我们的项目中肯定是这种情况。然而，贫血域模型是一种反模式。

这两种想法可以共存吗？

编辑：几个与上下文相关的链接：

SRP - http://www.objectmentor.com/resources/articles/srp.pdf
贫血域模型 - http://martinfowler.com/bliki/AnemicDomainModel.html

我不是那种只喜欢寻找先知并遵循他们所说的福音的开发人员。因此，我不提供这些链接作为说明“这些是规则”的一种方式，只是作为这两个概念定义的来源。