小话设计模式（零）设计模式可以满足你对编程的所有幻想（误）

什么是设计模式span style=”text-indent:28px”>设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结

为什么使用设计模式span style=”text-indent:28px”>使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

上面被划掉的是我从百度百科设计模式中直接复制粘贴过来的。既然划掉了，那么就说一下我的理解。

设计模式是编程过程中的一种中间层面的技巧或者经验（微观层面的如算法、数据结构、语法，宏观层面的如框架、工具箱、系统架构）。编程其实很简单，会写“Hello world”就是会编程了，会使用if和for语句就算是码农了，那么如何成为一个优秀的程序员需要积累经验，需要学习别人的有效和高效的方法，需要总结技巧，而这些经验、方法、技巧里就包含了设计模式。设计模式就是你在遇到一个具体问题时，可以想到最优秀最合理的解决方案。

我们之所以要使用设计模式，是因为优秀的程序员都是很懒的，我们（虽然我并不是足够优秀，但是我足够懒）在遇到似曾相识的问题的时候，不愿意把写过的代码再写一遍，我们希望可以不修改或者少量修改以前的代码就可以解决新的问题。而且，因为懒，所以不愿意写注释，所以不愿意花太多的时间向其他程序员解释我们的代码，而且，当我们回头看自己以前写的代码的时候，也希望不花太多时间可以尽快理顺，所以我们需要一个思路清晰的代码结构。设计模式可以满足你对编程的所有幻想。

虽然是老生常谈，但是不得不谈，23种（权威）设计模式：

创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。

结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。

行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式、访问者模式。

我们会在后面的文章中一一介绍这些设计模式，如果有机会的话，我们也会扩展介绍其他的设计模式。

附上这23种设计模式的关系图

最后简单介绍一下面向对象的几大原则：

1、单一职责原则

当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型责任，当这个类需要承担其他类型的责任的时候，就需要分解这个类。 

例：你不能要求一个程序员既会写程序又会招聘，如果你需要招聘新员工的时候，还是专门找一个HR或者猎头比较好。

2、开闭原则

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

例：有程序员这么一个类型的职业，你可以派生出C++程序员、Java程序员、C#程序员、会PS的C#程序员、不喜欢写注释的程序员，这就是开原则。但你不能要求所有的程序员都会C++、会Java、会C#、会PS且会C#、不喜欢写注释，这就是闭原则。

3、依赖倒转原则

高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

例：公司高层不应该依赖于低层的程序员，想开掉就开掉，大不了再招一个（苦逼的程序员要重新找工作了……）。程序员这个职业不应该依赖于某个特定的编程语言，而会了某一种编程语言，你就可以称为程序员了。

4、接口隔离原则

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。

例：讨论UI的时候还是不要叫上服务器程序员了。

5、里氏替换原则

任何基类可以出现的地方，子类一定可以出现。

例：员工上下班都需要打卡，那么程序员上下班也需要打卡，如果你看到一个人上下班没有打卡，那可能是老板。

5、组合/聚合复用原则

要尽量使用合成/聚合，尽量不要使用继承。

例：组建一个新团队的时候，如果先把老团队的人全部拉过来再按照需要招人的话，可能并不是所有人都有事情做。

6、最小知识原则

就是说一个对象应当对其他对象有尽可能少的了解。

例：作为一个策划（或者PM），不需要了解程序是怎么实现的，只要提需求就行了。“上联：这个需求很简单，下联：怎么实现我不管，横批：明天上线。”

小话设计模式（番外一）插件模式

小话设计模式（番外二）委托模式

小话设计模式（番外三）有限状态机模式

来源：凯奥斯