0. 前言
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
0.1 UML图
统一建模语言（Unified Modeling Language，UML）
详见之前一篇文章UML类图
1. 设计模式的三大分类
共有23种设计模式，可以分为3类：
- 创建型（Creational）：
- 结构型（Structural）：
- 行为型（Behavioral）：
(1) 创建型（5种）
- 工厂方法模式（Factory Method） 重要程度：5
- 抽象工厂模式（Abstract Factory） 重要程度：5
- 简单工厂模式（Simple Factory） 重要程度：4 （后来添加的）
- 单例模式（Singleton） 重要程度：4
- 原型模式（Prototype） 重要程度：3
- 建造者模式（Builder） 重要程度：2
- 外观模式（Facade） 重要程度：5
- 适配器模式（Adapter） 重要程度：4
- 组合模式（Composite） 重要程度：4
- 代理模式（Proxy） 重要程度：4
- 装饰模式（Decorator） 重要程度：3
- 桥接模式（Bridge） 重要程度：3
- 享元模式（Flyweight） 重要程度：1
- 观察者模式（Observer） 重要程度：5
- 迭代器模式（Iterator） 重要程度：5
- 命令模式（Command） 重要程度：4
- 策略模式（Stragety） 重要程度：4
- 责任链模式（Chain of Responsibility） 重要程度：3
- 状态模式（State） 重要程度：3
- 模板方法模式（Template Method） 重要程度：3
- 中介者模式（Mediator） 重要程度：2
- 备忘录模式（Memento） 重要程度：2
- 解释器模式（Interpreter） 重要程度：1
- 访问者模式（Visitor） 重要程度：1
定义：所有引用基类的地方必须能透明地使用其子类的对象。
通俗地讲：只要父类能出现的地方子类就能出现，而且替换为子类也不会产生任何错误或异常。反之就不行了，有子类出现的地方，父类未必就能适应。
好处：增强程序的健壮性，即使增加了子类，原有的子类还可以继续运行。
需要注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系 采用依赖、聚合、组合等关系代替继承。
(3) 依赖倒置原则（Dependence Inversion Principle, DIP）
定义：高层模块不应该依赖底层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
通俗地讲：模块间的依赖通过抽象产生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
好处：扩展性提高、解耦
需要注意：依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖与低层次的模块的实现细节的目的。
(4) 接口隔离原则（Interface Segregation Principle, ISP）
定义：类之间的依赖关系应该建立在最小的接口上。
通俗地讲：建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。
也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
需要注意：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化，所以一定要适度。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
- 为依赖接口的类定制服务。只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
(5) 迪米特定律（Law of Demeter, LoD）
也称为最少知识原则（Least Knowledge Principle）
定义：一个对象应该对其他对象有最少的了解。
通俗地讲：一个类应该对自己依赖的类知道得越少越好。
自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。
无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。
低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。
(6) 开闭原则（Open Close Principle, OCP）
定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
通俗地讲：在软件的生命周期内，变化（升级和维护等）一定会发生。当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
然而，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。
5554
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
