设计模式分为三大类：
（1）创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
（2）结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
（3）行为型模式，共十一种：策略模式、模板法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
这些设计模式特别关注对象之间的通信。
1、策略模式（STRATEGY PATTERN）
将每一个算法封装起来，而且使它们还可以相互替换，策略模式让算法独立于使用它的客户而独立变化。
使用场景：
如果在一个系统有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为；一个系统需要动态地在几种算法中选择一种； 如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现 。
优点 ：
策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，使用多重条件判断是非常不容易维护的。
缺点：
维护各个策略类会给开发带来额外开销，策略类的数量超过5个，就比较令人头疼了。必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的。
2、代理模式（静态和动态）（Proxy Pattern）
给某一个对象提供一个代理，并且由代理对象控制对原对象的引用
使用场景：
客户端在使用一个功能时，不希望直接使用其接口，而是希望通过一个代理去完成其功能。类似于现实生活中，人们买、租房时常常会通过中介代理，由中介帮客户相关事项，而且代理常常可以为用户完成一些相关性工作，例如办理手续等。
优点：
1）代理模式实现使用者与真实处理者的分离，降低系统的耦合度；
2）调用接口时，便于扩展一些业务无关的其他操作，不影响愿系统；
缺点：
- 增加类代理角色，性能上比直接使用低；
3、单例模式（Singleton Pattern）
保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。
单例模式有三个要点：
1).是某个类只能有一个实例；
2).是它必须自行创建这个实例；
3).是它必须自行向整个系统提供这个实例。
应用场景：
(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。
(2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
优点：
A.提供了对唯一实例的受控访问。
B.由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
C.允许可变数目的实例。
缺点：
A.由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。
B.单例类的职责过重，在一定程度上违背了“单一职责原则”。
C.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。
4、工厂方法模式（Factory Method Pattern）
工厂方法模式（FACTORY METHOD）是一种常用的对象创建型设计模式,此模式的核心精神是封装类中不变的部分，提取其中个性化善变的部分为独立类，通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。它的核心结构有四个角色，分别是抽象工厂、具体工厂、抽象产品、具体产品。
应用场景：
首先，工厂方法模式是new一个对象的替代品，所以在所有有需要的生成对象的地方都可以使用，但是需要慎重的考虑是否需要增加一个工厂类进行管理，增加代码的复杂度。
其次，需要灵活的，可扩张的框架时，可以考虑工厂方法模式。
再次，工厂方法模式可以用于异构项目中。
最后，可以使用在测试驱动开发的框架下。
优点：
1)、良好的封装性，代码结构清晰。
2)、工厂方法模式的扩展性非常优秀。
3)、屏蔽产品类、解耦。
5、抽象工厂模式（Abstract Factory Pattern）
为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。
应用场景：
当一个对象都有相同的约束时，可以使用抽象工厂模式。 打个比方说，这个工厂的几个产品都需要经过某些共同的步骤和打上相同的商标，这一组产品可以在一个工厂里面生产，减少很多重复的代码在不同的地方都出现多次。
优点
针对同一组产品创建新的生产线，只需实现那组产品的抽象工厂接口即可创建新的工厂类。
缺点
抽象方法模式的最大缺点就是产品族本身的扩展非常困难。如果在产品族中增加一个新的产品类型，则需要修改多个接口，并影响现已有的工厂类。
6、外观模式（Facade Pattern）
外观模式，一般用在子系统与访问之间，用于对访问屏蔽复杂的子系统调用采用耳目一新的外观类提供的简单的调用方法，具体的实现由外观类去子系统调用。外观模式任然是一种中间件类型的模式，使用外观模式之后子系统的方法调用并非完全屏蔽，只是为访问者提供了一种更佳的访问方式。
应用场景：
当我们访问的子系统拥有复杂额结构，内部调用繁杂，初接触者根本无从下手时，不凡由资深者为这个子系统设计一个外观类来供访问者使用，统一访问路径（集中到外观类中），将繁杂的调用结合起来形成一个总调用写到外观类中，之后访问者不用再繁杂的方法中寻找需要的方法进行调用，直接在外观类中找对应的方法进行调用即可。
还有就是在系统与系统之间发生调用时，也可以为被调用子系统设计外观类，这样方便调用也，屏蔽了系统的复杂性。
7、适配器模式（Adapter Pattern）
将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
应用场景：
1、已经存在的类的接口不符合我们的需求；
2、创建一个可以复用的类，使得该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作；
3、在不对每一个都进行子类化以匹配它们的接口的情况下，使用一些已经存在的子类。
优点：
1、将目标类和适配者类解耦
2、增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性
3、灵活性和扩展性都非常好，符合开闭原则
缺点：
1、对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为接口，不能为类，其使用有一定的局限性，不能将一个适配者类和他的子类同时适配到目标接口。
8、模板方法模式（TEMPLATE METHOD PATTERN）
模板方法就是为多种类似业务提供一个算法执行的统一框架，把这些业务中共同的部分抽取出来进行具体实现，而某些业务中特定的需求推迟到子类中进行重写实现。
适用场景：
一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是Opdyke和Johnson所描述过的“重分解以一般化”的一个很好的例子。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
控制子类扩展。模板方法只在特定点调用“hook”操作，这样就只允许在这些点进行扩展。
优点：
1.封装不变部分，扩展可变部分（封装性好）
2.提取公共部分代码，便于维护（复用性好）
3.行为由父类控制，子类实现（屏蔽细节）
缺点：
由于Java是单继承，我们面对一个旧系统进行重构的时候，原系统就有继承，我们想用模板方法重构再次引入继承就会比较困难。
9、建造者模式（BUILDER PATTERN）
将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。
应用场景：
1、需要生成的对象具有复杂的内部结构。
2、需要生成的对象内部属性本身相互依赖。
与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
建造者模式是在当创建复杂对象的复杂算法一个独立与该对象的组成部分以及它们的装配方式时适用的模式。
优点：
建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，
所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。
10、桥接模式（BRIDGE PATTERN）
将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。
应用场景：
(1)如果一个系统需要在抽象化和具体化之间增加更多的灵活性，避免在两个层次之间建立静态的继承关系，通过桥接模式可以使它们在抽象层建立一个关联关系。
(2)“抽象部分”和“实现部分”可以以继承的方式独立扩展而互不影响，在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统需要对抽象化角色和实现化角色进行动态耦合。
(3)一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展。
(4)对于那些不希望使用继承或因为多层继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
优点：
(1)分离抽象接口及其实现部分。桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度的变化，也就是说抽象和实现不再在同一个继承层次结构中，而是“子类化”它们，使它们各自都具有自己的子类，以便任何组合子类，从而获得多维度组合对象。
(2)在很多情况下，桥接模式可以取代多层继承方案，多层继承方案违背了“单一职责原则”，复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它极大减少了子类的个数。
(3)桥接模式提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合“开闭原则”。
缺点:
(1)桥接模式的使用会增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程。
(2)桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性，如何正确识别两个独立维度也需要一定的经验积累。
11、命令模式（COMMAND PATTERN）
将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
应用场景：
(1) 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
(2) 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者可以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，可以通过请求日志文件等机制来具体实现。
(3) 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
(4) 系统需要将一组操作组合在一起形成宏命令。
优点：
(1) 降低系统的耦合度。由于请求者与接收者之间不存在直接引用，因此请求者与接收者之间实现完全解耦，相同的请求者可以对应不同的接收者，同样，相同的接收者也可以供不同的请求者使用，两者之间具有良好的独立性。
(2) 新的命令可以很容易地加入到系统中。由于增加新的具体命令类不会影响到其他类，因此增加新的具体命令类很容易，无须修改原有系统源代码，甚至客户类代码，满足“开闭原则”的要求。
(3) 可以比较容易地设计一个命令队列或宏命令（组合命令）。
(4) 为请求的撤销(Undo)和恢复(Redo)操作提供了一种设计和实现方案。
缺点:
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调用操作都需要设计一个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这将影响命令模式的使用。
12、装饰模式（DECORATOR PATTERN）
在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。
应用场景：
1、需要扩展一个类的功能。
2、动态的为一个对象增加功能，而且还能动态撤销。（继承不能做到这一点，继承的功能是静态的，不能动态增删。）
优点：其拓展性十分良好，通过使用不同的装饰类来使得对象具有多种多样的属性，灵活性比直接继承好。
缺点：产生了过多的装饰类，代码难于理解，不易于排错。
13、迭代器模式（ITERATOR PATTERN）
提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示
应用场景：
1、访问一个聚合对象的内容而无须暴露它的内部表示。
2、需要为聚合对象提供多种遍历方式。
3、为遍历不同的聚合结构提供一个统一的接口。
优点：
简化了遍历方式，对于对象集合的遍历，还是比较麻烦的，对于数组或者有序列表，我们尚可以通过游标来取得，但用户需要在对集合了解很清楚的前提下，自行遍历对象，但是对于hash表来说，用户遍历起来就比较麻烦了。而引入了迭代器方法后，用户用起来就简单的多了。
可以提供多种遍历方式，比如说对有序列表，我们可以根据需要提供正序遍历，倒序遍历两种迭代器，用户用起来只需要得到我们实现好的迭代器，就可以方便的对集合进行遍历了。
封装性良好，用户只需要得到迭代器就可以遍历，而对于遍历算法则不用去关心。
缺点：
对于比较简单的遍历（像数组或者有序列表），使用迭代器方式遍历较为繁琐，大家可能都有感觉，像ArrayList，我们宁可愿意使用for循环和get方法来遍历集合。
14、组合模式（COMPOSITE PATTERN）
组合多个对象形成树形结构以表示具有“整体—部分”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，组合模式又可以称为“整体—部分”(Part-Whole)模式，它是一种对象结构型模式。
应用场景：
(1) 在具有整体和部分的层次结构中，希望通过一种方式忽略整体与部分的差异，客户端可以一致地对待它们。
(2) 在一个使用面向对象语言开发的系统中需要处理一个树形结构。
(3) 在一个系统中能够分离出叶子对象和容器对象，而且它们的类型不固定，需要增加一些新的类型。
优点：
(1) 组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让客户端忽略了层次的差异，方便对整个层次结构进行控制。
(2) 客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。
(3) 在组合模式中增加新的容器构件和叶子构件都很方便，无须对现有类库进行任何修改，符合“开闭原则”。
(4) 组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，通过叶子对象和容器对象的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。
缺点：
在增加新构件时很难对容器中的构件类型进行限制。有时候我们希望一个容器中只能有某些特定类型的对象，例如在某个文件夹中只能包含文本文件，使用组合模式时，不能依赖类型系统来施加这些约束，因为它们都来自于相同的抽象层，在这种情况下，必须通过在运行时进行类型检查来实现，这个实现过程较为复杂。
15、观察者模式（OBSERVER PATTERN）
在对象之间定义了一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象会收到通知并自动更新。
应用场景:
一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
一个对象必须通知其他对象，而并不知道这些对象是谁。
需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。
优点：
- 观察者和被观察者是抽象耦合的。
2、建立一套触发机制。
缺点：
1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
16、责任链模式（CHAIN OF RESPONSIBILITY PATTERN）
将能够处理同一类请求的对象连成一条链，如果不能处理则传递给链上的下一个对象。
应用场景：
1 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
2 你想在不明确指定接受者的情况下，想过个对象中的一个提交一个请求。
3 可处理一个请求的对象集合应该被动态指定。
优点：
1、降低耦合度。它将请求的发送者和接收者解耦。
2、简化了对象。使得对象不需要知道链的结构。
3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
4、增加新的请求处理类很方便。
缺点：
1、不能保证请求一定被接收。
2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
3、可能不容易观察运行时的特征，有碍于除错。
106
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
