每个程序员都应牢记的7种坏味道，11种原则，23种模式

每个程序员都应牢记的7种坏味道，11种原则，23种模式

(一)7种设计坏味道
1.僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
2.脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3.牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
4.粘滞性： 做正确的事情比做错误的事情要困难。
5.复杂性(不必要的)： 设计中包含有不具任何直接好处的基础结构。
6.重复性(不必要的)： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
7.晦涩性： 很难阅读、理解。没有很好地表现出意图。

(二)11种原则 - Principle
----类原则
1.单一职责原则 - Single Responsibility Principle(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
(职责即为“变化的原因”。)
2.开放-封闭原则 - Open Close Principle(OCP)
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
(对于扩展是开放的,对于更改是封闭的.
关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来.
开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.
拒绝不成熟的抽象和抽象本身一样重要. )
3.里氏替换原则 - Liskov Substitution Principle(LSP)
子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
(Hollywood原则: "Don't call us, we'll call you".
程序中所有的依赖关系都应该终止于抽象类和接口。
针对接口而非实现编程。
任何变量都不应该持有一个指向具体类的指针或引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写他的任何基类中的已经实现了的方法。)
5.接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。
接口属于客户，不属于它所在的类层次结构。
(多个面向特定用户的接口胜于一个通用接口。)
----包内聚原则
6.重用发布等价原则(REP)
重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响，
则将对该包中的所有类产生影响，
而对于其他的包不造成任何影响。
8.共同重用原则(CRP)
一个包中的所有类应该是共同重用的。
如果重用了包中的一个类，
那么就要重用包中的所有类。
(相互之间没有紧密联系的类不应该在同一个包中。)
----包耦合原则
9.无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中，
不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。
11.稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
(一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. )
----其它扩展原则----
12.BBP(Black Box Principle)黑盒原则
多用类的聚合，少用类的继承。
13.DAP(Default Abstraction Principle)缺省抽象原则
在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.
14.IDP(Interface Design Principle)接口设计原则
规划一个接口而不是实现一个接口。
15.DCSP(Don't Concrete Supperclass Principle)不要构造具体的超类原则
避免维护具体的超类。
16.迪米特法则
一个类只依赖其触手可得的类。

(三)23种设计模式 - Pattern.
创建型
Abstract Factory（抽象工厂模式） -> (简单工厂模式)
Factory Method（工厂模式）
Builder（生成器模式）
Singleton（单件模式） -> (多例模式)
Prototype（原型模式）
结构型
Adapter（适配器模式）
Bridge（桥接模式）
Composite（组合模式）
Decorator（装饰模式）
Facade（外观模式，门面模式）
Flyweight（享元模式） -> (不变模式)
Proxy（代理模式）
行为型
Chain of Responsibility（职责链模式）
Command（命令模式）
Interpreter（解释器模式）
Iteartor（迭代器模式）
Mediator（中介者模式）
Memento（备忘录模式）
Observer（观察者模式）
State（状态模式）
Strategy（策略模式）
TemplateMethod（模板方法模式）
Visitor（访问者模式）

评论

9 楼 javatar 2006-12-28  

fins 写道

全称怎么写啊??
我英语太烂了 :'(

全称是：Keep it Simple, Stupid
我英语也很烂,这里高手不少，希望还有的救。

Godlikeme 写道

跟据场景套模式。模式对应的是问题的场景，是一种抽象层次更高的编程。对于多数问题，能够KISS是最好的，不用为了模式而模式。

赞同你的观点，KISS是Practical的真理，利用模式，而不是被模式利用！

8 楼 Godlikeme 2006-12-28  

fins 写道

全称怎么写啊??
我英语太烂了 :'(

keep it simple, stupid.

7 楼 fins 2006-12-28  

全称怎么写啊??
我英语太烂了 :'(

6 楼 抛出异常的爱 2006-12-28  

保持简单，傻瓜

5 楼 fins 2006-12-28  

"能够KISS是最好的" kiss什么意思啊?? 呵呵 见笑了

4 楼 Godlikeme 2006-12-28  

fins 写道

javatar似乎一直都很重视模式
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵

设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了

现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去

我想很多人都应该有我这样的困惑吧
郁闷...

跟据场景套模式。模式对应的是问题的场景，是一种抽象层次更高的编程。对于多数问题，能够KISS是最好的，不用为了模式而模式。

3 楼 jin.libing 2006-12-28  

还不太是太理解程序员的生活。刚出来。。。。。

2 楼 fins 2006-12-28  

javatar似乎一直都很重视模式
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵

设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了

现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去

我想很多人都应该有我这样的困惑吧
郁闷...

1 楼 凤舞凰扬 2006-12-28  

    记是没有用的，更重要的是要理解它，这种理解不仅仅是理解它怎么样，更多的是理解为什么要这么用，它的好处和缺点何在。