架构设计中的几项原则

架构设计中的几项原则

做个笔记：

DIP——Dependency Inversion Principle依赖倒置原则：
1、高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
2、抽象不应该依赖于细节,细节应该依赖于抽象。

高层模块包含了一个应该程序中的重要的策略选择和业务模型，正是这些高层模块才使得其所有的应用程序区别于其他，如果高层依赖于低层,那么对低层模块的改动就会直接影响到高层模块,从而迫使它们依次做出改动。

OCP——Open-Closed Principle开关原则：
Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification。
软件实体应当对扩展开放，对修改关闭，即软件实体应当在不修改（在.Net当中可能通过代理模式来达到这个目的）的前提下扩展。
Open for extension:当新需求出现的时候，可以通过扩展现有模型达到目的。    
Close for modification:对已有的二进制代码，如dll,jar等，则不允许做任何修改。

ISP简介（ISP——Interface Segregation Principle）接口分离原则：
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

SRP简介（SRP——Single-Responsibility Principle）单一职责原则：
就一个类而言，应该只专注于做一件事和仅有一个引起它变化的原因。

所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个变化会要求我们修改这个类，那么你就要考虑撤分这个类了。因为职责是变化的一个轴线，当需求变化时，该变化会反映类的职责的变化。
“就像一个人身兼数职，而这些事情相互关联不大，，甚至有冲突，那他就无法很好的解决这些职责，应该分到不同的人身上去做才对。”

LSP简介（LSP——Liskov Substitution Principle）Liskov替换原则：
定义：如果对于类型S的每一个对象O1，都有一个类型T的对象O2，使对于任意用类型T定义的程序P，将O2替换为O1，P的行为保持不变，则称S为T的一个子类型。
子类型必须能够替换它的基类型。LSP又称里氏替换原则。
对于这个原则，通俗一些的理解就是，父类的方法都要在子类中实现或者重写。

REP简介：The Release Reuse Equivalency Principle 重用发布等价原则：
重用粒度等价于发布粒度。也就是说，一个为重用目的而设计的发布单位里，不能包含不可重用的元素；如果包含了不可重用的元素，它将变得不可重用。

CRP简介：Common Reuse Principle共同重用原则：
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。相互之间没有紧密练习的类不应该放在同一包里。