设计模式作为一组抽象的设计思想,肯定有一些基本的原则.否则的话,任何设计都可以称之为"良好设计"的一种了.
在设计模式中,也有整体"不允许"和"需要遵循"的方方面面.只要遵循了下面这些基本思想,写出来的设计往往都是很优秀的设计.
- 7种坏味道
- 僵化性: 说白了就是整个系统过于僵硬,没办法或很难针对其中的某个需要修改的地方做灵活的调整,牵一发而动全身.
- 脆弱性: 这次可以调整了,但是仍然关联性太强,一个位置的小调整竟然会导致一堆逻辑上毫无关联的位置出现新的问题.
- 牢固性: 系统从一开始逻辑关联就设计得过于紧密.这次系统里设计的功能模块与组件,在另一个系统的类似需求中无法复用.
- 粘滞性: 软件架构的设计不够优美,从而导致在代码维护中难以遵循已有的设计思路顺理成章的完成新的需求,很容易,也很希望能够打破原先的结构另辟蹊径来完成新的功能,从而导致软件的整体质量和维护时间的不可预计.
- 复杂性: 设计中有些冗余的结构,到后期会发现连设计者都不清楚它们是用来干啥的...
- 重复性: 很多时候,看起来必须的一大堆结构或定义,完全可以用一个统一的接口抽象.
- 晦涩性: 整个设计就是个迷宫,写文档的时候都无法清晰的找出整个设计的逻辑和层次.
- 11种原则
- 单一职责原则: 每当你设计一个模块的时候,这个模块肯定会随着需求而变化.但是能够引起它变化的需求应该只有一类.
- 开放-封闭原则: 我们的模块应该可以通过拓展而不是修改来满足新的需求.
- 里氏替换原则: 一个抽象的具体实现(子类型)应该能够完全替换抽象所在的位置,这个原则保证了子类型的接口实现与抽象的预期是相符的.
- 依赖倒置原则: 抽象应该封装细节,从而使抽象完全独立于真正的细节实现;而不是由具体的实现来决定抽象应该怎么做.
- 接口隔离原则: 不应该让对外的接口过于抽象,从而增加接口调用的复杂性.应该由外部的具体需求去决定接口的定义.这里要注意分离出易变的需求与不变的需求.
- 重用发布等价原则: 对外发布的系统是模块化的.那么我们发布的最终产品的每个模块都应该是可重用的,独立的模块.
- 共同封闭原则: 一个变化若影响了当前的系统,那么它应该仅会影响到我们系统中的一个模块.
- 共同重用原则: 模块是自身封闭的闭包.当需要重用这个模块中的一部分时,我们需要将这个模块整体重用,但是不应该涉及到其它的模块.
- 无环依赖原则: 模块之间的相互依赖关系不能形成环形
- 稳定依赖原则: 不稳定的易变的模块应该依赖于更加稳定的模块,而不是相反.
- 稳定抽象原则: 最稳定的模块应该是最抽象的,不稳定的模块应该是具体实现,模块的抽象程度跟它的稳定性成正比.
- 其他拓展原则
- BBP(Black Box Principle)黑盒原则: 多用组合,少用继承.继承是耦合度很高的设计,而组合则可以比较轻松的将模块之间拆分开.
- DAP(Default Abstraction Principle)缺省抽象原则: 在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作,这样可以提供一些相对统一的接口实现,避免用同样的方法重复的实现一些通用的接口.
- IDP(Interface Design Principle)接口设计原则: 规划一个接口而不是实现一个接口.其实就是接口的设计应该依赖于具体需求
- DCSP(Don't Concrete Supperclass Principle)不要构造具体的超类原则: 很简单,超类应该是接口,接口就不应该存在具体的超类.接口不应该是具体的实现,而应该是抽象的定义,实现的封装.
- 迪米特法则: 每个模块应该专注于自己自身的需求,而尽量少的干涉其他模块.
更多内容请访问：http://darkc.at