一些OOD设计原则

1. 类的设计原则
SRP, 单一职责原则,一个类应该有且只有一个改变的理由。
OCP, 开放封闭原则,你应该能够不用修改原有类就能扩展一个类的行为。
LSP, Liskov替换原则,派生类要与其基类自相容。
DIP, 依赖倒置原则,依赖于抽象而不是实现。
ISP, 接口隔离原则,客户只要关注它们所需的接口。


2. 包内聚性的设计原则
REP, 重用发布等价原则,重用的粒度就是发布的粒度。
CCP, 共同封闭原则,包中的所有类对于同一类性质的变化应该是共同封闭的。 
CRP, 共同重用原则,一个包中的所有类应该是共同重用的。


3包之间的耦合性的设计原则
ADP, 无环依赖原则,在包的依赖关系图中不允许存在环。
SDP, 稳定依赖原则,朝着稳定的方向进行依赖。
SAP, 稳定抽象原则,包的抽象程度应该和其稳定程度一致。


这里的包是指如dll, lib, jar等.


我觉得这些设计原则都很好, 是经验的总结, 但不能为了用而用, 适合就好.
熟悉了才知道适不适合, 用多了才能更深刻的体会.


http://book.51cto.com/art/200903/114676.htm

http://blog.csdn.net/rmartin/article/details/1299516




1.单一职责原则(SRP)


单一职责原则的核心思想就是:系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成。它的英文缩写是SRP,英文全称是Single Responsibility Principle。


其实单一职责原则的意思就是开发人员经常说的"高内聚、低耦合"。也就是说,每个类应该只有一个职责,对外只能提供一种功能,而引起类变化的原因应该只有一个。在设计模式中,所有的设计模式都遵循这一原则。


2.开闭原则(OCP)


开闭原则的核心思想就是:一个对象对扩展开放,对修改关闭。它的英文缩写是OCP,英文全称是Open for Extension,Closed for Modification。


其实开闭原则的意思就是:对类的改动是通过增加代码进行的,而不是改动现有的代码。也就是说,软件开发人员一旦写出了可以运行的代码,就不应该去改变它,而是要保证它能一直运行下去,如何才能做到这一点呢?这就需要借助于抽象和多态,即把可能变化的内容抽象出来,从而使抽象的部分是相对稳定的,而具体的实现层则是可以改变和扩展的。


3.里氏替换原则(LSP)


里氏替换原则的核心思想就是:在任何父类出现的地方都可以用它的子类来替代。它的英文缩写是LSP,英文全称是Liskov Substitution Principle。


其实里氏替换原则的意思就是:同一个继承体系中的对象应该有共同的行为特征。里氏代换原则关注的是怎样良好地使用继承,也就是说不要滥用继承,它是继承复用的基石。


4.依赖注入原则(DIP)


依赖注入原则的核心思想就是:要依赖于抽象,不要依赖于具体的实现。它的英文缩写是DIP,英文全称是Dependence Inversion Principle。


其实依赖注入原则的意思就是:在应用程序中,所有的类如果使用或依赖于其他的类,则都应该依赖于这些其他类的抽象类,而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节,这样才能保证系统的可复用性和可维护性。为了实现这一原则,就要求开发人员在编程时要针对接口编程,而不针对实现编程。


5.接口分离原则(ISP)


接口分离原则的核心思想就是:不应该强迫客户程序依赖它们不需要使用的方法。它的英文缩写是ISP,英文全称是Interface Segregation Principle。


其实接口分离原则的意思就是:一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口当中。


6.迪米特原则(LOD)


迪米特原则的核心思想就是:一个对象应当对其他对象尽可能少的了解。它的英文缩写是LOD,英文全称是Law of Demeter。


其实迪米特原则的意思就是:降低各个对象之间的耦合,提高系统的可维护性。在模块之间,应该只通过接口来通信,而不理会模块的内部工作原理,它可以使各个模块耦合程度降到最低,促进软件的复用。


7.优先使用组合而不是继承原则(CARP)


优先使用组合而不是继承原则的核心思想就是:优先使用组合,而不是继承。它的英文缩写是CARP,英文全称是Composite/Aggregate Reuse Principle。


其实优先使用组合而不是继承原则的意思就是:在复用对象的时候,要优先考虑使用组合,而不是继承,这是因为在使用继承时,父类的任何改变都可能影响子类的行为,而在使用组合时,是通过获得对其他对象的引用而在运行时刻动态定义的,有助于保持每个类的单一职责原则。

你可能感兴趣的:(一些OOD设计原则)