OOD的原则
良好的设计,就是系统容易理解、容易改变、容易重用。
设计的“异味”
- 僵化性(Rigidity)——系统很难改变,因为改动一处,就不得不改动其他地方,甚至引起无休止的连锁反应
- 易碎性(Fragility)——改变某个部分,会破坏很多完全无关的部分
- 固化性(Immobility)——很难将系统分解成可供其他系统重用的组件
- 粘稠性(Viscosity)——永远走不出编辑-编译-测试这一无休止的循环
- 不必要的复杂性(Needless Complexity)——很多非常聪明的代码结构目前还不需要,但有一天可能用上
- 不必要的重复性(Needless Repetition)——代码看上去是两个叫剪切和粘贴的程序员写的
- 不透明性(Opacity)——
单一职责原则(The Single Responsibility Principle - SRP)
一个类只能因为一个原因而改变
在UML图中,找一找那些与多个主题域存在依赖关系的类。
开放-封闭原则(The Open-Close Principle - OCP)
在UML图中,找一找那些与多个主题域存在依赖关系的类。
软件实体(类、模块、方法等)应该允许扩展,不许修改
应该可在不改变模块本身的情况下改变模块周围的环境
里斯科夫替换原则(The Liskov Subsitution Principle - LSP)
子类型必须能够替代它们的基类型
LSP指出,基类用户不必为了使用派生类而做任何特殊的事情。确切的说,它们不应该需要使用instanceof,也不必向下转型。实际上,它们根本不需要了解派生类,甚至不必知道是否存在派生类。
依赖关系倒置原则(The Dependency Inversion Principle - DIP)
A.上层模块应该不依赖于下层模块。它们都依赖于抽象。
B.抽象应该不依赖于细节。细节应该依赖于抽象。
不要依赖易变的具体类。从UML的角度看,顺着UML图中的每个箭头,检查箭头的顶端指向的是否是一个接口或抽象类。如果不是,而且指向的具体类是会改变的,那么就违反了DIP。
接口隔离原则(The Interface Segregation Principle - ISP)
B.抽象应该不依赖于细节。细节应该依赖于抽象。
不要依赖易变的具体类。从UML的角度看,顺着UML图中的每个箭头,检查箭头的顶端指向的是否是一个接口或抽象类。如果不是,而且指向的具体类是会改变的,那么就违反了DIP。
客户端不应该依赖于自己不用的方法。
遵循一个简单的规则——为使用者提供只包含了它们要用到的方法的接口——就可以保护使用者被不用的方法影响