类的设计原则总结整理

a,单一职责原则
我们把职责定义为“变化的原因”。如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责
l,Rectangle类具有两个方法，一个方法把矩形绘制在屏幕上，另一个方法计算矩形面积,这个设计违反了SRP。Rectangle类具有两个职责。第一个职责提供了矩形几何形状数学模型；第二个职责是把矩形在一个图形用户界面上绘制出来
2,软件设计真正要做到的许多内容，就是发现职责，并把那些职责相互分离
==========================================
a,开放－封闭原则（OCP）
1,对于扩展是开放的（Open for extension）
2,对于更改是封闭的（Closed for modification）
3,怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？——关键是抽象
结论：OCP是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是：灵活性、可重用性以及可维护性）。

=====================================
a,里氏替换
1，OOD中IS-A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序所依赖的
2，事物的分类学
俗语“IS-A”的含义过于宽泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显式或隐式的契约来定义。

里氏替换作用：正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展

=============================
b,依赖倒置
1，如果高层模块依赖底层模块，则依赖关系是传递。
2，我们通常会认为工具库应该拥有它们自己的接口。但是当应用了DIP时，我们发现，往往是客户端拥有抽象接口，而它们的服务者这从这些抽象接口派生
3，这就是著名的Hollywood原则：“Don’t call us, we’ll call you.”（不要调用我们，我们会调用你。）低层模块实现了在高层模块中声明并被高层模块调用的接口
4，我们在应用程序中所编写的大多数具体类都是不稳定的。我们不想直接依赖于这些不稳定的具体类。通过把它们隐藏在抽象接口的后面，可以隔离它们的不稳定性
5，抽象接口维系的隔离性
6，由客户来声明它需要的服务接口，那么仅当客户需要时才会对接口进行改变。这样，改变实现抽象接口的类就不会影响到客户
7，由于抽象和细节彼此隔离，所以代码也非常容易维护

结论：使用传统的过程化程序设计所创建出来的依赖关系结构，策略是依赖于细节的。这是糟糕的，因为这样会使策略受到细节改变的影响。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口
================================
c：接口隔离
1，这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的（cohesive），
2，不应该强迫客户依赖于它们不要的方法。接口属于客户，不属于它所在的类层次结构
3，换句话说，类的“胖”接口可以分解成多组方法。每一组方法都服务于一组不同的客户程序。这样，一些客户程序可以使用一组成员函数，而其他客户程序可以使用其他组的成员函数。这会存在很大的问题
4，如果强迫客户程序依赖于那些它们不使用的方法，那么这些客户程序就面临着由于这些没使用的方法的改变所带来的变更。这无意中导致了所有客户程序之间的耦 合。我们希望尽可能地避免这种耦合，因此我们希望分离接口
结论：胖类（fat class）会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时，会影响到所有其他的客户程序，每个特定于客户程序的接口仅仅声明它的特 定客户或者客户组调用的那些函数。接着，该胖类就可以继承所有特定于客户程序的接口，并实现它们。这就解决了客户程序和它们没有调用的方法间的依赖关系， 并使客户程序之间互不依赖

 

361sky.taobao.com 伊柜1985

361pig.taobao.com 艺人1987