（1）设计模式是人们在面对同类型软件工程设计问题所总结出的一些有用经验。模式不是代码，而是某类问题的通用设计解决方案
（2）4人组Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides总结写了《设计模式》
（3）设计模式的优点和用途
（4）学习设计模式最好的方式：在你的设计和以往的工程里寻找何处可以使用它们
（5）设计模式的本质目的是使软件工程在维护性、扩展性、变化性、复杂度方面成O(N)
（6）OO(面向对象)是原则，设计模式是具体方法、工具
对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。
面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是我们用于评价一个设计模式的使用效果的重要指标之一，在设计模式的学习中，大家经常会看到诸如“XXX模式符合XXX原则”、“XXX模式违反了XXX原则”这样的语句。
单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下：
开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。开闭原则由Bertrand Meyer于1988年提出，其定义如下：
开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。
为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。
在很多面向对象编程语言中都提供了接口、抽象类等机制，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。
注意：因为xml和properties等格式的配置文件是纯文本文件，可以直接通过VI编辑器或记事本进行编辑，且无须编译，因此在软件开发中，一般不把对配置文件的修改认为是对系统源代码的修改。如果一个系统在扩展时只涉及到修改配置文件，而原有的Java代码或C#代码没有做任何修改，该系统即可认为是一个符合开闭原则的系统。
如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这个定义比较拗口且难以理解，因此我们一般使用它的另一个通俗版定义：
里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
在使用里氏代换原则时需要注意如下几个问题：
(1)子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
(2) 我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。
(3) Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。
依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。
在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。
接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构，比如Java语言中的interface。对于这两种不同的含义，ISP的表达方式以及含义都有所不同：
(1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫做“角色隔离原则”。
(2) 如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。
合成复用原则又称为组合/聚合复用原则(Composition/Aggregate Reuse Principle, CARP)，其定义如下：
合成复用原则(Composite Reuse Principle, CRP)：尽量使用对象组合，而不是继承来达到复用的目的。
合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合聚合关系（关联关系），少用继承。
在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。
由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
一般而言，如果两个类之间是“Has-A”的关系应使用组合或聚合，如果是“Is-A”关系可使用继承。"Is-A"是严格的分类学意义上的定义，意思是一个类是另一个类的"一种"；而"Has-A"则不同，它表示某一个角色具有某一项责任。
迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP)，其定义如下：
迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。
迪米特法则还有几种定义形式，包括：不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类：
(1) 当前对象本身(this)；
(2) 以参数形式传入到当前对象方法中的对象；
(3) 当前对象的成员对象；
(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
(5) 当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。
迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。
在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
策略模式：分别封装行为接口，实现算法族，超类里放行为接口对象，在子类里具体设定行为对象。原则就是：分离变化部分，封装接口，基于接口编程各种功能。此模式让行为算法的变化独立于算法的使用者。
代码：
（1）首先提供不同行为的抽象接口
CodeBehavior.java
package cn.melo.strategy;
// 抽象敲代码的接口
public interface CodeBehavior {
//提供敲代码的方法
void code();
}
DriveBehavior.java
package cn.melo.strategy;
// 抽象出驾驶员的接口
public interface DriveBehavior {
//提供驾驶的接口
void drive();
}
（2）提供这两个接口的实现类，有会驾驶，不会驾驶，会打代码，不会打代码
HaveDriveBehavior.java
package cn.melo.strategy;
//会开车的实现类
public class HaveDriveBehavior implements DriveBehavior {
NoDriveBehavior.java
package cn.melo.strategy;
//不会开车的实现类
public class NoDriveBehavior implements DriveBehavior {
HaveCodeBehavior.java
package cn.melo.strategy;
//会打代码的实现类
public class HaveCodeBehavior implements CodeBehavior {
NoCodeBehavior.java
package cn.melo.strategy;
//不会打代码的实现类
public class NoCodeBehavior implements CodeBehavior {
（3）提供顶层的抽象类
Person.java
package cn.melo.strategy;
?
// Person的超类
public abstract class Person {
DriveBehavior driveBehavior;
CodeBehavior codeBehavior;
public Person() {}
//驾驶的方法
public void drive() {
driveBehavior.drive();
}
// 打代码的方法
public void code() {
codeBehavior.code();
}
// 打印信息的方法
public abstract void showInfo();
//人都要吃饭
public void eat() {
System.out.println("每个人都会吃饭！！");
}
}
（4）提供顶层超类的具体实现类
CarDriver.java
package cn.melo.strategy;
?
//会驾驶，不会打代码的人
public class CarDriver extends Person {
public CarDriver() {
// 把实现类的对象赋值给行为
driveBehavior = new HaveDriveBehavior();
codeBehavior = new NoCodeBehavior();
}
JavaCoder.java
package cn.melo.strategy;
//只会打代码，而不会驾驶的人
public class JavaCoder extends Person {
public JavaCoder() {
driveBehavior = new NoDriveBehavior();
codeBehavior = new HaveCodeBehavior();
}
?
（5）测试类
test.java
package cn.melo.strategy;
?
public class Test {
public static void main(String[] args) {
//创建对象
CarDriver carDriver = new CarDriver();
JavaCoder javaCoder = new JavaCoder();
carDriver.showInfo();
carDriver.eat();
carDriver.drive();
carDriver.code();
System.out.println("----------------");
javaCoder.showInfo();
javaCoder.eat();
javaCoder.drive();
javaCoder.code();
测试结果：
我是xxx，来自xxx，只会开小车
每个人都会吃饭！！
我会开汽车！！
不会打代码！
----------------
我是yyyy,来自yyyy，只会打Java代码
每个人都会吃饭！！
不会驾驶！！
会打代码！！
?
策略模式的主要目的是将算法的定义与使用分开，也就是将算法的行为和环境分开，将算法的定义放在专门的策略类中，每一个策略类封装了一种实现算法，使用算法的环境类针对抽象策略类进行编程，符合“依赖倒转原则”。在出现新的算法时，只需要增加一个新的实现了抽象策略类的具体策略类即可。
策略模式的主要优点如下：
(1) 策略模式提供了对“开闭原则”的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。
(2) 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族，恰当使用继承可以把公共的代码移到抽象策略类中，从而避免重复的代码。
(3) 策略模式提供了一种可以替换继承关系的办法。如果不使用策略模式，那么使用算法的环境类就可能会有一些子类，每一个子类提供一种不同的算法。但是，这样一来算法的使用就和算法本身混在一起，不符合“单一职责原则”，决定使用哪一种算法的逻辑和该算法本身混合在一起，从而不可能再独立演化；而且使用继承无法实现算法或行为在程序运行时的动态切换。
(4) 使用策略模式可以避免多重条件选择语句。多重条件选择语句不易维护，它把采取哪一种算法或行为的逻辑与算法或行为本身的实现逻辑混合在一起，将它们全部硬编码(Hard Coding)在一个庞大的多重条件选择语句中，比直接继承环境类的办法还要原始和落后。
(5) 策略模式提供了一种算法的复用机制，由于将算法单独提取出来封装在策略类中，因此不同的环境类可以方便地复用这些策略类。
策略模式的主要缺点如下：
(1) 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
(2) 策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。
(3) 无法同时在客户端使用多个策略类，也就是说，在使用策略模式时，客户端每次只能使用一个策略类，不支持使用一个策略类完成部分功能后再使用另一个策略类来完成剩余功能的情况。
在以下情况下可以考虑使用策略模式：
(1) 一个系统需要动态地在几种算法中选择一种，那么可以将这些算法封装到一个个的具体算法类中，而这些具体算法类都是一个抽象算法类的子类。换言之，这些具体算法类均有统一的接口，根据“里氏代换原则”和面向对象的多态性，客户端可以选择使用任何一个具体算法类，并只需要维持一个数据类型是抽象算法类的对象。
(2) 一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重条件选择语句来实现。此时，使用策略模式，把这些行为转移到相应的具体策略类里面，就可以避免使用难以维护的多重条件选择语句。
(3) 不希望客户端知道复杂的、与算法相关的数据结构，在具体策略类中封装算法与相关的数据结构，可以提高算法的保密性与安全性。
观察者模式就像订报纸业务：
1）报社，Subject
2）用户，Observer
Subject接口：登记注册(registObserver)、移除(removeObserver)和通知(notifyObserver)
Observer接口：接收通知(update)
观察者模式： 对象之间多对一依赖的一种设计方案，被依赖的对象为Subject，依赖的对象为Observer，Subject通知Observer变化, 观察者模式的别名包括发布订阅（Publish/Subscribe）模式、模型视图（Model/View）模式、源监听器（Source/Listener）模式或从属者（Dependents）模式。
代码：
观察者(相当于订阅报纸的人的抽象)
Observer.java
package cn.melo.observer;
?
/**
* 这是观察者的顶层接口，相当于订报纸的人的抽象接口
*/
public interface Observer {
void update();
}
目标接口(或者称主题，相当于报馆的抽象)
subject.java
package cn.melo.observer;
/**
* 假如说这是一个报社
*/
public interface Subject {
// 注册观察者的方法
void registObserver(Observer observer);
// 移除观察者的方法
void removeObserver(Observer observer);
//通知观察者的方法
void notifyObserver();
}
现某地有两位订阅报纸的人
第一位 ObserverImpl.java
package cn.melo.observer;
?
/**
* 这是观察者的实现类：相当于某个订阅报纸的人！
*/
public class ObserverImpl implements Observer {
?
第二位：ObserverImpl1.java
package cn.melo.observer;
?
/**
* 这是观察者的实现类：相当于某个订阅报纸的人！
*/
public class ObserverImpl2 implements Observer {
?
这是当地的一家报馆：
SubjectImpl.java
package cn.melo.observer;
?
import java.util.HashSet;
import java.util.Set;
?
/**
* 具体的目标，相当于某家报馆
*/
public class SubjectImpl implements Subject {
Set<Observer> set = new HashSet<Observer>();
?
测试：Test.java
package cn.melo.observer;
?
public class Test {
public static void main(String[] args) {
//创建报馆对象
Subject sub = new SubjectImpl();
//创建两个订阅报纸的人的对象
Observer o1 = new ObserverImpl();
Observer o2 = new ObserverImpl2();
//分别到报馆订阅报纸
sub.registObserver(o1);
sub.registObserver(o2);
//以后报馆就会每天分别给他们送报纸
sub.notifyObserver();
System.out.println("---------------");
//某一天第一个观察者不想看报纸了，于是取消订阅
sub.removeObserver(o1);
//从此以后，报馆还是每天送报纸，但是不会给第一个观察者了
sub.notifyObserver();
}
}
结果：
我是第二个观察者，我要两份报纸！！
我是第一个观察者，我要一份报纸！
---------------
我是第二个观察者，我要两份报纸！！
观察者模式描述了如何建立对象与对象之间的依赖关系，以及如何构造满足这种需求的系统。观察者模式包含观察目标和观察者两类对象，一个目标可以有任意数目的与之相依赖的观察者，一旦观察目标的状态发生改变，所有的观察者都将得到通知。作为对这个通知的响应，每个观察者都将监视观察目标的状态以使其状态与目标状态同步，这种交互也称为发布-订阅(Publish-Subscribe)。观察目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者，可以有任意数目的观察者订阅它并接收通知。
在当前流行的MVC(Model-View-Controller)架构中也应用了观察者模式，MVC是一种架构模式，它包含三个角色：模型(Model)，视图(View)和控制器(Controller)。其中模型可对应于观察者模式中的观察目标，而视图对应于观察者，控制器可充当两者之间的中介者。当模型层的数据发生改变时，视图层将自动改变其显示内容。
观察者模式的主要优点如下：
(1) 观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
(2) 观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须了解其具体观察者。由于观察目标和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
(3) 观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度。
(4) 观察者模式满足“开闭原则”的要求，增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标之间不存在关联关系的情况下，增加新的观察目标也很方便。
观察者模式的主要缺点如下：
(1) 如果一个观察目标对象有很多直接和间接观察者，将所有的观察者都通知到会花费很多时间。
(2) 如果在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
(3) 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
在以下情况下可以考虑使用观察者模式：
(1) 一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两个方面封装在独立的对象中使它们可以各自独立地改变和复用。
(2) 一个对象的改变将导致一个或多个其他对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这些对象是谁。
(3) 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。
装饰模式(Decorator Pattern)：动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。
代码（模拟麦当劳的套餐）：
首先提供一个顶层接口，抽象构建角色：Food.java
package cn.melo.decorator;
?
/**
* 顶层抽象接口，模拟在麦当劳点餐的食物
*
*/
public interface Food {
String getDesc();
}
基础的套餐，具体的构建角色
package cn.melo.decorator;
?
/**
* 基本套餐
*/
public class Basic implements Food {
?
抽象装饰者角色，就是套餐的抽象SetMenue.java
package cn.melo.decorator;
?
/**
* 抽象装饰者角色
* 就是订单
*
*/
public abstract class SetMenu implements Food {
Food food;
public SetMenu(Food food) {
this.food = food;
}
具体的装饰者，即具体的套餐：SetMenue1.java和SetMenue2.java
package cn.melo.decorator;
?
/**
* 套餐一
* 具体的装饰类
*
*/
public class SetMenu1 extends SetMenu {
?
public SetMenu1(Food food) {
super(food);
}
package cn.melo.decorator;
?
public class SetMenu2 extends SetMenu {
?
public SetMenu2(Food food) {
super(food);
}
测试：
package cn.melo.decorator;
?
public class Test {
?
public static void main(String[] args) {
// 创建出基本的套餐
Food f = new Basic();
// 选择套餐1
SetMenu1 setMenu1 = new SetMenu1(f);
System.out.println(setMenu1.getDesc());
// 套餐3：组合套餐1和套餐2
SetMenu setMenu3 = new SetMenu2(setMenu1);
System.out.println("套餐3：" + setMenu3.getDesc());
}
?
}
结果：
汉堡+可乐+薯条
套餐3：汉堡+可乐+薯条+炸鸡
最经典的装饰者模式的就是jdk提供的类BufferedInputStream，BufferedOutputStream，BufferedReader，BufferedWriter；
装饰模式降低了系统的耦合度，可以动态增加或删除对象的职责，并使得需要装饰的具体构件类和具体装饰类可以独立变化，以便增加新的具体构件类和具体装饰类。在软件开发中，装饰模式应用较为广泛，例如在JavaIO中的输入流和输出流的设计、javax.swing包中一些图形界面构件功能的增强等地方都运用了装饰模式。 装饰模式的主要优点如下：
(1) 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。
(2) 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的具体装饰类，从而实现不同的行为。
(3) 可以对一个对象进行多次装饰，通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合，得到功能更为强大的对象。
(4) 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，原有类库代码无须改变，符合“开闭原则”。
装饰模式的主要缺点如下：
(1) 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接的方式有所不同，而不是它们的类或者属性值有所不同，大量小对象的产生势必会占用更多的系统资源，在一定程序上影响程序的性能。
(2) 装饰模式提供了一种比继承更加灵活机动的解决方案，但同时也意味着比继承更加易于出错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为繁琐。 在以下情况下可以考虑使用装饰模式：
(1) 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
(2) 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰模式。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种扩展或者扩展之间的组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因为类已定义为不能被继承（如Java语言中的final类）。
单例模式(Singleton Pattern)：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。
单例模式有三个要点：一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。
代码：
最初的做法：
Singletone1.java
package cn.melo.singleton;
?
/**
* 单例模式
*/
public class Singleton1 {
// 首先在内部创建一个自己静态的私有对象
private static Singleton1 singleton;
// 然后私有化构造方法
private Singleton1() {}
// 提供一个静态方法
public static Singleton1 getInstance() {
if(singleton == null) {
singleton = new Singleton1();
}
return singleton;
}
}
测试：
package cn.melo.singleton;
?
public class Test {
public static void main(String[] args) {
Singleton1 s1 = Singleton1.getInstance();
Singleton1 s2 = Singleton1.getInstance();
Singleton1 s3 = Singleton1.getInstance();
Singleton1 s4 = Singleton1.getInstance();
System.out.println(s1 + "," + s2 + "," + s3 + "," + s4);
System.out.println(s1 == s2 && s2 == s3 && s3 == s4);
}
}
结果：
cn.melo.singleton.Singleton1@2f92e0f4,cn.melo.singleton.Singleton1@2f92e0f4,cn.melo.singleton.Singleton1@2f92e0f4,cn.melo.singleton.Singleton1@2f92e0f4
true
但是这样做是线程不安全的，所以可以改变一下，变成：Singletone2.java
package cn.melo.singleton;
?
public class Singleton2 {
// 首先在内部创建一个自己静态的私有对象
private static Singleton2 singleton;
// 然后私有化构造方法
private Singleton2() {}
// 提供一个静态方法
public synchronized static Singleton2 getInstance() {
if(singleton == null) {
singleton = new Singleton2();
}
return singleton;
}
}
但是每次访问这个方法都要加锁也是很影响效率的，所以改成：Singleton3.java
“急切”创建实例：
package cn.melo.singleton;
?
public class Singleton3 {
// 首先在内部创建一个自己静态的私有对象
private static Singleton3 singleton = new Singleton3();
// 然后私有化构造方法
private Singleton3() {}
// 提供一个静态方法
public static Singleton3 getInstance() {
return singleton;
}
}
测试：
package cn.melo.singleton;
?
public class Test {
public static void main(String[] args) {
Singleton3 s1 = Singleton3.getInstance();
Singleton3 s2 = Singleton3.getInstance();
Singleton3 s3 = Singleton3.getInstance();
Singleton3 s4 = Singleton3.getInstance();
System.out.println(s1 + "," + s2 + "," + s3 + "," + s4);
System.out.println(s1 == s2 && s2 == s3 && s3 == s4);
}
}
结果：
cn.melo.singleton.Singleton3@2f92e0f4,cn.melo.singleton.Singleton3@2f92e0f4,cn.melo.singleton.Singleton3@2f92e0f4,cn.melo.singleton.Singleton3@2f92e0f4
true
这种方案不好的地方在于如果没有使用该对象，只是使用了该类的其他静态，它也会把实例创建出来，造成了资源浪费！
最后还有一种优化， 双重检查加锁 ：Singleton4.java
package cn.melo.singleton;
?
public class Singleton4 {
?
// 首先在内部创建一个自己静态的私有对象
private volatile static Singleton4 singleton;
?
// 然后私有化构造方法
private Singleton4() {}
?
// 提供一个静态方法
public static Singleton4 getInstance() {
// 如果为空，才加锁
if (singleton == null) {
synchronized(Singleton4.class) {
if (singleton == null) {
singleton = new Singleton4();
}
}
}
return singleton;
?
}
}
测试：
package cn.melo.singleton;
?
public class Test {
public static void main(String[] args) {
Singleton4 s1 = Singleton4.getInstance();
Singleton4 s2 = Singleton4.getInstance();
Singleton4 s3 = Singleton4.getInstance();
Singleton4 s4 = Singleton4.getInstance();
System.out.println(s1 + "," + s2 + "," + s3 + "," + s4);
System.out.println(s1 == s2 && s2 == s3 && s3 == s4);
}
}
结果：
cn.melo.singleton.Singleton4@2f92e0f4,cn.melo.singleton.Singleton4@2f92e0f4,cn.melo.singleton.Singleton4@2f92e0f4,cn.melo.singleton.Singleton4@2f92e0f4
true
单例模式的主要优点如下：
(1) 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。
(2) 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
(3) 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例，既节省系统资源，又解决了单例单例对象共享过多有损性能的问题。
单例模式的主要缺点如下：
(1) 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
(2) 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
(3) 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。
在以下情况下可以考虑使用单例模式：
(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。
(2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
原文：https://www.cnblogs.com/meloHe/p/12441369.html