如何将 SOLID 原则实施到现有项目中 [英] How to implement SOLID principles into an existing project

问题描述

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

I apologize for the subjectiveness of this question, but I am a little stuck and I would appreciate some guidance and advice from anyone who's had to deal with this issue before:

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

I have (what's become) a very large RESTful API project written in C# 2.0 and some of my classes have become monstrous. My main API class is an example of this -- with several dozen members and methods (probably approaching hundreds). As you can imagine, it's becoming a small nightmare, not only to maintain this code but even just navigating the code has become a chore.

我对 SOLID 原则相当陌生，而且我是设计模式的忠实粉丝(但我仍处于可以实现它们的那个阶段，但不知道何时该<强>使用它们 - 在不那么明显的情况下).

I am reasonably new to the SOLID principles, and I am massive fan of design patterns (but I am still at that stage where I can implement them, but not quite enough to know when to use them - in situations where its not so obvious).

我需要缩小课程的规模，但我不知道如何最好地做到这一点.我的 StackOverflow 伙伴们能否提出一些方法，让他们采用现有的代码单体并将其缩小到一定程度?

I need to break my classes down in size, but I am at a loss of how best to go about doing it. Can my fellow StackOverflow'ers please suggest ways that they have taken existing code monoliths and cut them down to size?

推荐答案

单一职责原则 - 一个类应该只有一个改变的理由.如果你有一个整体类，那么它可能有不止一个改变的理由.简单地定义你改变的一个原因，并尽可能细化合理.我建议从大"开始.将三分之一的代码重构到另一个类中.一旦你有了它，然后从你的新课程开始.直接从一个班级到 20 个班级太令人生畏了.

Single Responsibility Principle - A class should have only one reason to change. If you have a monolithic class, then it probably has more than one reason to change. Simply define your one reason to change, and be as granular as reasonable. I would suggest to start "large". Refactor one third of the code out into another class. Once you have that, then start over with your new class. Going straight from one class to 20 is too daunting.

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

Open/Closed Principle - A class should be open for extension, but closed for change. Where reasonable, mark your members and methods as virtual or abstract. Each item should be relatively small in nature, and give you some base functionality or definition of behavior. However, if you need to change the functionality later, you will be able to add code, rather than change code to introduce new/different functionality.

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

Liskov Substitution Principle - A class should be substitutable for its base class. The key here, in my opinion, is do to inheritance correctly. If you have a huge case statement, or two pages of if statements that check the derived type of the object, then your violating this principle and need to rethink your approach.

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

Interface Segregation Principle - In my mind, this principle closely resembles the Single Responsibility principle. It just applies specifically to a high level (or mature) class/interface. One way to use this principle in a large class is to make your class implement an empty interface. Next, change all of the types that use your class to be the type of the interface. This will break your code. However, it will point out exactly how you are consuming your class. If you have three instances that each use their own subset of methods and properties, then you now know that you need three different interfaces. Each interface represents a collective set of functionality, and one reason to change.

依赖倒置原则 - 父母/孩子的寓言让我明白了这一点.想想父类.它定义行为，但不关心肮脏的细节.它是可靠的.然而，子类是关于细节的，不能依赖，因为它经常变化.你总是想依赖父类、负责任的类，而不是相反.如果您有一个依赖于子类的父类，那么当您更改某些内容时会出现意外行为.在我看来，这与 SOA 的心态相同.服务合同定义了输入、输出和行为，但没有详细信息.

Dependency Inversion Principle - The parent / child allegory made me understand this. Think of a parent class. It defines behavior, but isn't concerned with the dirty details. It's dependable. A child class, however, is all about the details, and can't be depended upon because it changes often. You always want to depend upon the parent, responsible classes, and never the other way around. If you have a parent class depending upon a child class, you'll get unexpected behavior when you change something. In my mind, this is the same mindset of SOA. A service contract defines inputs, outputs, and behavior, with no details.

当然，我的观点和理解可能不完整或错误.我建议向已经掌握这些原则的人学习，比如鲍勃叔叔.对我来说一个很好的起点是他的书，敏捷原则，模式, 以及 C# 中的实践.另一个很好的资源是 Bob 叔叔关于 Hanselminutes.

Of course, my opinions and understandings may be incomplete or wrong. I would suggest learning from people who have mastered these principles, like Uncle Bob. A good starting point for me was his book, Agile Principles, Patterns, and Practices in C#. Another good resource was Uncle Bob on Hanselminutes.

当然，正如 Joel 和 Jeff 指出的，这些是原则，而不是规则.它们将成为帮助指导您的工具，而不是法律.

Of course, as Joel and Jeff pointed out, these are principles, not rules. They are to be tools to help guide you, not the law of the land.

我刚刚发现这些 SOLID 截屏视频，看起来非常有趣.每一个大约 10-15 分钟.

I just found these SOLID screencasts which look really interesting. Each one is approximately 10-15 minutes long.

这篇关于如何将 SOLID 原则实施到现有项目中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！