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

Posted 2022-10-23 Shawn_Dut

　　其实很早就想开始总结设计模式了，无奈刚刚换完工作，工作太忙，平时周末也太懒，难得提起精神写一点，估计时间会花的很长，不过还是自己加油吧~~。
　　学习笔记，顾名思义，其实就是我在平时看书，工作的笔记而已，只不过分享出来让大家有什么错误的给指点一下，能学到知识当然也是很好的 (￣▽￣)” 。
　　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 的子类型。上面这种描述确实不太好理解，我们再看看另一个直截了当的定义，里氏替换原则第二种定义：所有引用基类的地方必须能透明的使用其子类的对象。
　　面向对象的语言的三大特点就是继承、封装和多态，里氏替换原则就是依赖于继承和多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明的使用其子类的对象。通俗来讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
• 子类中可以增加自己特有的方法；
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

看上去很不可思议，因为我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑的好好的。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？后果就是：你写的代码出问题的几率将会大大增加。
　　 设计模式六大原则（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（访问者模式）：封装一些作用于某种数据结构中的个元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。

其他特殊模式

　　Object Pool（对象池模式）：维护一定数量的对象集合，使用时直接向对象池申请，以跳过对象的 expensive initialization 。

源码下载

　　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