我为这个问题的主观性而道歉,但我有点卡住了,我希望以前能够处理这个问题的人提供一些指导和建议:
我有(成为什么)一个用C#2.0编写的非常大的RESTful API项目,我的一些类变得非常可怕.我的主要API类就是一个例子 - 有几十个成员和方法(可能接近数百个).你可以想象,它变成了一个小噩梦,不仅仅是维护这段代码,甚至只是导航代码已经成为一件苦差事.
我是SOLID原则的新手,我是设计模式的忠实粉丝(但我仍处于可以实现它们的那个阶段,但还不足以知道何时使用它们 - 在不太明显的情况下) .
我需要打破我的班级规模,但我不知道如何最好地去做.我的StackOverflower伙伴能否建议他们采用现有的代码单块并将其缩小到适当大小？
单一责任原则 - 一个班级应该只有一个改变的理由.如果你有一个单一的类,那么它可能有不止一个改变的理由.只需定义您改变的一个原因,并尽可能合理.我建议开始"大".将三分之一的代码重构为另一个类.一旦你有了,那么重新开始你的新课程.直接从一个班级到20个班级太令人生畏了.
开放/封闭原则 - 一个类应该是可以扩展的,但是对于更改是关闭的.在合理的情况下,将您的成员和方法标记为虚拟或抽象.每个项目本质上应该相对较小,并为您提供一些基本功能或行为定义.但是,如果您以后需要更改功能,则可以添加代码,而不是更改代码以引入新的/不同的功能.
Liskov替换原则 - 一个类应该可以替代它的基类.在我看来,这里的关键是正确地进行继承.如果你有一个巨大的case语句,或两个if语句检查对象的派生类型,那么你违反了这个原则,需要重新考虑你的方法.
界面隔离原则 - 在我看来,这个原则与单一责任原则非常相似.它只适用于高级(或成熟)类/接口.在大类中使用此原则的一种方法是使您的类实现一个空接口.接下来,将使用您的类的所有类型更改为接口的类型.这会破坏你的代码.但是,它会指出你如何消耗你的课程.如果您有三个实例,每个实例都使用自己的方法和属性子集,那么您现在知道需要三个不同的接口.每个接口代表一组集合的功能,以及一个改变的原因.
依赖倒置原则 - 父/子寓言使我理解这一点.想想一个父类.它定义了行为,但不关心脏的细节.这是可靠的.然而,子类是关于细节的,并且不能依赖它,因为它经常变化.你总是希望依赖父母,负责任的课程,而不是相反.如果您有一个父类,具体取决于子类,当您更改某些内容时,您将遇到意外行为.在我看来,这与SOA的思维方式相同.服务合同定义了输入,输出和行为,没有任何细节.
当然,我的意见和理解可能是不完整或错误的.我建议向那些掌握了这些原则的人学习,比如鲍勃叔叔.对我来说,一个很好的起点是他的书,即C#中的敏捷原则,模式和实践.另一个很好的资源是Hanselminutes上的Uncle Bob.
当然,正如乔尔和杰夫指出的那样,这些是原则,而不是规则.它们是帮助指导你的工具,而不是土地法则.
编辑:
我刚刚发现这些看起来非常有趣的SOLID截屏视频.每个约10-15分钟长.
京公网安备 11010802040832号 | 京ICP备19059560号-6 