java/android 设计模式学习笔记目录

　　其实很早就想开始总结设计模式了，无奈刚刚换完工作，工作太忙，平时周末也太懒，难得提起精神写一点，估计时间会花的很长，不过还是自己加油吧~~。
　　学习笔记，顾名思义，其实就是我在平时看书，工作的笔记而已，只不过分享出来让大家有什么错误的给指点一下，能学到知识当然也是很好的 (￣▽￣)” 。
　　PS：对技术感兴趣的同鞋加群544645972一起交流

java/android设计模式

介绍

　　设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。一个设计模式并不是能够用于代码中的，而是提供一个在不同情况下解决问题的模板示例。设计模式允许开发者用一个大家都熟知的编码方式进行交流，有利于软件的扩展性和可维护性。

职责

　　设计模式当然也需要遵循面向对象设计的6大原则：

单一职责原则

　　单一职责的英文名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装，所以如果类执行的功能过多就要考虑将类进行拆分了。
　　设计模式六大原则（1）：单一职责原则

开闭原则

　　开闭原则的英文全称是Open Close Principle，缩写是OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的（open for extension and close for modification）。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在实际开发过程中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。所以为了保证在软件不断迭代的过程中确保原有软件模块的正确性，以及尽量少地影响原有模块，还是应该尽量遵守本章描述的开闭原则。
　　设计模式六大原则（6）：开闭原则

里氏替换原则

　　里氏替换原则英文全称是Liskov Substitution Principle， 缩写是LSP。LSP 的第一种定义是：如果对每一个类型为 S 的对象 O1，都有类型为 T 的对象 O2， 使得以 T 定义的所有程序 P 在所有的对象 O1，都代换成 O2 时，程序 P 的行为没有发生变化，那么类型 S 是类型 T 的子类型。上面这种描述确实不太好理解，我们再看看另一个直截了当的定义，里氏替换原则第二种定义：所有引用基类的地方必须能透明的使用其子类的对象。
　　面向对象的语言的三大特点就是继承、封装和多态，里氏替换原则就是依赖于继承和多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明的使用其子类的对象。通俗来讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应，其实最终总结就两个字：抽象。
　　设计模式六大原则（2）：里氏替换原则

依赖倒置原则

　　依赖倒置原则英文全称是Dependence Inversion Principle ，缩写是DIP。依赖倒置原则指代了一种特定的解耦形势，使得高层次的模块不依赖于低层次的模块实现细节的目的，依赖模块被颠倒了。依赖倒置原则有以下几个关键点

1. 高层模块不应该依赖底层模块，两者都应该依赖其抽象；
2. 抽象不应该依赖细节；
3. 细节应该依赖抽象。

　　在 Java 中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以直接通过 new 产生一个对象。高层模块就是调用端，底层模块就是具体实现类。依赖倒置原则在 Java 中的表现就是： 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象精髓之一。
　　 设计模式六大原则（3）：依赖倒置原则

接口隔离原则

　　接口隔离原则英文全称是 InterfaceSegregation Principles，缩写是ISP。ISP 的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
　　设计模式六大原则（4）：接口隔离原则

迪米特原则

　　迪米特原则英文全称为 Law of Demeter， 缩写是LOD，也称为最少知识原则（Least Konwledge Principle）。虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。类与类之间的关系越密切，耦合度就越大，当一个类发生改变时，对另一个类的影响也越大。
　　迪米特法则还有一个英文解释是 Only talk to your immediate friends，翻译过来就是：只与直接的朋友通信。什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，有组合、聚合、依赖等。
　　设计模式六大原则（5）：迪米特法则

设计模式分类

创建型模式

　　Abstract Factory（抽象工厂模式）：
　　Builder（建造者模式）：
　　Factory Method（工厂方法模式）：
　　Prototype（原型模式）：
　　Singleton（单例模式）：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

结构型模式

　　Adapter（适配器模式）：
　　Bridge（桥接模式）：
　　Composite（外观模式）：
　　Decorator（装饰者模式）：
　　Facade（外观模式）：
　　Flyweight（享元模式）：
　　Proxy（代理模式）：

行为型模式

　　Chain of responsibility（责任链模式）：
　　Command（命令模式）：
　　Interpreter（解释器模式）：
　　Iterator（迭代器模式）：
　　Mediator（中介者模式）：
　　Memento（备忘录模式）：
　　Observer（观察者模式）：
　　State（状态模式）：
　　Strategy（策略模式）：
　　Template method（模板方法模式）：
　　Visitor（访问者模式）：

源码下载

　　https://github.com/zhaozepeng/Design-Patterns

引用

https://en.wikipedia.org/wiki/Singleton_pattern
https://en.wikipedia.org/wiki/Design_Patterns
http://blog.csdn.net/jason0539/article/details/44956775