c# - 如何在现有项目中实现 SOLID 原则

Question

对于这个问题的主观性，我深表歉意，但我有点卡住了，我很感激以前处理过这个问题的人的一些指导和建议:

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

我对 SOLID 原则相当陌生，而且我是设计模式的忠实拥护者(但我仍处于可以实现它们的阶段，但还不足以知道何时< strong>使用它们——在不太明显的情况下)。

我需要缩小类(class)规模，但我不知道如何才能做到最好。我的 StackOverflow 同事们能否建议他们采用现有代码单体并将其缩小规模的方法？

Answer 1

单一职责原则 - 一个类应该只有一个改变的理由。如果你有一个单一的类，那么它可能有不止一个改变的理由。简单地定义你改变的一个原因，并尽可能地合理。我建议从“大”开始。将三分之一的代码重构到另一个类中。一旦你有了它，然后重新开始你的新类(class)。从一节课直接到 20 节课太可怕了。

开放/封闭原则 - 一个类应该对扩展开放，但对变更关闭。在合理的情况下，将您的成员和方法标记为虚拟或抽象。每个项目本质上应该相对较小，并为您提供一些基本功能或行为定义。但是，如果您以后需要更改功能，您将能够添加代码，而不是更改代码以引入新的/不同的功能。

Liskov 替换原则 - 一个类应该可以替换它的基类。在我看来，这里的关键是正确地继承。如果你有一个巨大的 case 语句，或者两页的 if 语句来检查对象的派生类型，那么你就违反了这个原则，需要重新考虑你的方法。

接口(interface)隔离原则 - 在我看来，这个原则与单一职责原则非常相似。它仅适用于高级(或成熟的)类/接口(interface)。在大型类中使用此原则的一种方法是让您的类实现一个空 接口(interface)。接下来，将所有使用您的类的类型更改为接口(interface)的类型。这会破坏你的代码。但是，它会准确指出您是如何类的。如果您有三个实例，每个实例都使用自己的方法和属性子集，那么您现在就知道需要三个不同的接口(interface)。每个界面代表一组功能，以及一个更改原因。

依赖倒置原则 - 父/子寓言让我明白了这一点。想想一个父类。它定义行为，但不关心肮脏的细节。这是可靠的。然而，子类是关于细节的，并且不能依赖，因为它经常变化。您总是希望依赖父级、负责的类，而不是相反。如果您有一个依赖于子类的父类，那么当您更改某些内容时，您会得到意想不到的行为。在我看来，这与 SOA 的思维方式相同。服务契约定义了输入、输出和行为，但没有详细信息。

当然，我的观点和理解可能不完整或错误。我建议向掌握这些原则的人学习，比如鲍勃叔叔。对我来说一个很好的起点是他的书，Agile Principles, Patterns, and Practices in C# .另一个很好的资源是 Uncle Bob on Hanselminutes .

当然，如Joel and Jeff pointed out ，这些是原则，不是规则。它们将成为帮助指导您的工具，而不是国家法律。

编辑:

我刚找到这些 SOLID screencasts看起来很有趣。每个大约 10-15 分钟。