设计模式基础

最近业余时间在看《Android 源码设计模式解析与实战》,对设计模式的一些知识，整理汇总一下！

通俗的讲，就是根据面向对象语言的思想，对代码进行优化，并总结出而行成的一种模板规范！（主要是为代码解耦）

本文参考了：

http://blog.csdn.net/banketree/article/details/24985607

http://blog.csdn.net/zhangerqing/article/details/8194653

参考的书籍有《Android 源码设计模式解析与实战》

类与类之间主要有6种关系，他们分别是：依赖、关联、聚合、组合、继承、实现。它们的耦合度依次增强。

依赖关系:
对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。
关联关系:
分为单向关联和双向关联。

单向关联表现为：类A当中使用了类B，其中类B是作为类A的成员变量。

双向关联表现为：类A当中使用了类B作为成员变量；同时类B中也使用了类A作为成员变量。
聚合关系:
是关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是“整体-个体”的相互关系。
组合关系：
是一种耦合度更强的关联关系。存在组合关系的类表示“整体-部分”的关联关系，“整体”负责“部分”的生命周期，他们之间是共生共死的；并且“部分”单独存在时没有任何意义。
继承：
表示类与类（或者接口与接口）之间的父子关系。
实现：
表示一个类实现一个或多个接口的方法。

其设计的原则

1）单一职责原则

每个类只负责单一的功能；

由来：

如一个类里实现了二种不同的功能，A和B；如其中A与B任一个功能改动都有可能影响对方的功能！

方案：

按单一职责原则，为A和B分别建单独的类，这样在修改需求时，都不会影响对方的！

2）里氏替换原则
其子类对象可以代替父类对象,但其父类对象不能代替子类对象.子类可以扩展父类的功能，但不能修改父类原有的功能。
由来：
CL类实现了A功能，后将A功能进行扩展成了B功能，B功能中除了含有A功能，还含有别一功能C。
功能B,由子类来完成，如在子类中做功能修改，有可能导致原有功能修改
方案：
按里氏替换原则,子类继承了父类（CL），在完成新增功能外，尽量不要修改父类中的方法功能！

3)依赖倒置原则
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程。

3）接口隔离原则
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

4）迪米特法则
一个对象应该对其他对象保持最少的了解。
由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

解决方案：尽量降低类与类之间的耦合。

5）开闭原则
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

设计模式的分类

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

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

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