【设计模式】设计模式篇
什么是设计模式
设计模式是一套经过反复使用的代码设计经验，目的是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式使得代码编写真正工程化，它是软件工程的基石。
总体来说，设计模式分为三大类：
- 创建型模式：共5种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
- 结构型模式：共7种：适配器模式、装饰器模式、代理模式、桥接模式、外观模式、组合模式、享元模式
- 行为型模式：共11种：策略模式、模板方法模式、观察者模式、责任链模式、访问者模式、中介者模式、迭代器模式、命令模式、状态模式、备忘录模式、解释器模式
其实还有两类：并发型模式和线程池模式。
设计模式的六大原则
开闭原则 (Open Close Principle)
开闭原则指的是对扩展开放，对修改关闭。在对程序进行扩展的时候，不能去修改原有的代码，想要达到这样的效果，我们就需要使用接口或者抽象类。
依赖倒转原则 (Dependence Inversion Principle)
依赖倒置原则是开闭原则的基础，指的是针对接口编程，依赖于抽象而不依赖于具体。
里氏替换原则 (Liskov Substitution Principle)
里氏替换原则是继承与复用的基石，只有当子类可以替换掉基类，且系统的功能不受影响时，基类才能被复用，而子类也能够在基础类上增加新的行为。所以里氏替换原则指的是任何基类可以出现的地方，子类一定可以出现。
里氏替换原则是对 “开闭原则” 的补充，实现 “开闭原则” 的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。
---- 我的理解：在传递变量的时候，使用接口或抽象类对象，这样在具体实现的实现的时候，就可以传递具体的实现类。
接口隔离原则 (Interface Segregation Principle)
使用多个隔离的接口，比使用单个接口要好，降低接口之间的耦合度与依赖，方便升级和维护方便。
迪米特原则 (Demeter Principle)
迪米特原则，也叫最少知道原则，指的是一个类应当尽量减少与其他实体进行相互作用，使得系统功能模块相对独立，降低耦合关系。该原则的初衷是降低类的耦合，虽然可以避免与非直接的类通信，但是要通信，就必然会通过一个“中介”来发生关系，过分的使用迪米特原则，会产生大量的中介和传递类，导致系统复杂度变大，所以采用迪米特法则时要反复权衡，既要做到结构清晰，又要高内聚低耦合。
合成复用原则 (Composite Reuse Principle)
尽量使用组合/聚合的方式，而不是使用继承。
工厂方法模式
简单工厂模式
建立一个工厂类，并定义一个接口对实现了同一接口的产品类进行创建。首先看下关系图：
工厂方法模式
工厂方法模式是对简单工厂模式的改进，简单工厂的缺陷在于不符合“开闭原则”，每次添加新产品类就需要修改工厂类，不利于系统的扩展维护。而工厂方法将工厂抽象化，并定义一个创建对象的接口。每增加新产品，只需增加该产品以及对应的具体实现工厂类，由具体工厂类决定要实例化的产品是哪个，将对象的创建与实例化延迟到子类，这样工厂的设计就符合“开闭原则”了，扩展时不必去修改原来的代码。UML关系图如下：
- 抽象工厂 AbstractFactory： 工厂方法模式的核心，是具体工厂角色必须实现的接口或者必须继承的父类，在 Java 中它由抽象类或者接口来实现。
- 具体工厂 Factory：被应用程序调用以创建具体产品的对象，含有和具体业务逻辑有关的代码
- 抽象产品 AbstractProduct：是具体产品继承的父类或实现的接口，在 Java 中一般有抽象类或者接口来实现。
- 具体产品 Product：具体工厂角色所创建的对象就是此角色的实例。
工厂方法模式详情文章：Java设计模式之创建型：工厂模式详解（简单工厂+工厂方法+抽象工厂）
单例模式
单例模式可以确保系统中某个类只有一个实例，该类自行实例化并向整个系统提供这个实例的公共访问点，除了该公共访问点，不能通过其他途径访问该实例。单例模式的优点在于：
- 系统中只存在一个共用的实例对象，无需频繁创建和销毁对象，节约了系统资源，提高系统的性能；
- 以严格控制客户怎么样以及何时访问单例对象。
单例模式的写法有好几种，这里主要介绍三种：懒汉式单例、饿汉式单例、登记式单例。
（1）懒汉式单例：双重检查锁定 和 静态内部类
① 双重检查锁定
//懒汉式单例类.在第一次调用的时候实例化自己
public class Singleton {
private Singleton() {}
private volatile static Singleton singleton=null;
public static Singleton getInstance() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}为什么 getInstance() 方法内需要使用两个 if (singleton == null) 进行判断呢？
假设高并发下，线程A、B 都通过了第一个 if 条件。若A先抢到锁，new 了一个对象，释放锁，然后线程B再抢到锁，此时如果不做第二个 if 判断，B线程将会再 new 一个对象。使用两个 if 判断，确保了只有第一次调用单例的时候才会做同步，这样也是线程安全的，同时避免了每次都同步的性能损耗。
volatile 关键字的作用？
volatile 的作用主要是禁止指定重排序。假设在不使用 volatile 的情况下，两个线程A、B，都是第一次调用该单例方法，线程A先执行 singleton = new Singleton()，但由于构造方法不是一个原子操作，编译后会生成多条字节码指令，由于 JAVA的 指令重排序，可能会先执行 singleton 的赋值操作，该操作实际只是在内存中开辟一片存储对象的区域后直接返回内存的引用，之后 singleton 便不为空了，但是实际的初始化操作却还没有执行。如果此时线程B进入，就会拿到一个不为空的但是没有完成初始化的singleton 对象，所以需要加入volatile关键字，禁止指令重排序优化，从而安全的实现单例。
② 静态内部类：
public class Singleton {
private static class LazyHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return LazyHolder.INSTANCE;
}
} （2）饿汉式
//饿汉式单例类.在类初始化时，已经自行实例化
public class Singleton1 {
private Singleton1() {}
private static final Singleton1 single = new Singleton1();
//静态工厂方法
public static Singleton1 getInstance() {
return single;
}
}饿汉式在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以天生是线程安全的。
（3）登记式
//类似Spring里面的方法，将类名注册，下次从里面直接获取。
public class Singleton3 {
private static Map<String,Singleton3> map = new ConcurrentHashMap<String,Singleton3>();
static{
Singleton3 single = new Singleton3();
map.put(single.getClass().getName(), single);
}
//保护的默认构造子
protected Singleton3(){}
//静态工厂方法,返还此类惟一的实例
public static Singleton3 getInstance(String name) {
if(name == null) {
name = Singleton3.class.getName();
System.out.println("name == null"+"--->name="+name);
}
if(map.get(name) == null) {
try {
map.put(name, (Singleton3) Class.forName(name).newInstance());
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
return map.get(name);
}
//一个示意性的商业方法
public String about() {
return "Hello, I am RegSingleton.";
}
public static void main(String[] args) {
Singleton3 single3 = Singleton3.getInstance(null);
System.out.println(single3.about());
}
}单例模式详情：Java设计模式之创建型：单例模式
装饰器模式
装饰器模式可以动态给对象添加一些额外的职责从而实现功能的拓展，在运行时选择不同的装饰器，从而实现不同的行为；比使用继承更加灵活，通过对不同的装饰类进行排列组合，创造出很多不同行为，得到功能更为强大的对象；符合“开闭原则”，被装饰类与装饰类独立变化，用户可以根据需要增加新的装饰类和被装饰类，在使用时再对其进行组合，原有代码无须改变。装饰器模式的UML结构图如下：
- Component：抽象构件，是定义一个对象接口，可以给这个对象动态地添加职责。
- ConcreteComponent：具体构件，是定义了一个具体的对象，也可以给这个对象添加一些职责。
- Decorator：抽象装饰类，继承自 Component，从外类来扩展 Component 类的功能，但对于 Component 来说，是无需知道 Decorator 存在的。
- ConcreteDecorator：具体装饰类，起到给 Component 添加职责的功能。
装饰者与被装饰者都拥有共同的超类，但这里继承的目的是继承类型，而不是行为。
装饰器模式详情：Java设计模式之结构型：装饰器模式
代理模式
代理模式的设计动机是通过代理对象来访问真实对象，通过建立一个对象代理类，由代理对象控制原对象的引用，从而实现对真实对象的操作。在代理模式中，代理对象主要起到一个中介的作用，用于协调与连接调用者(即客户端)和被调用者(即目标对象)，在一定程度上降低了系统的耦合度，同时也保护了目标对象。但缺点是在调用者与被调用者之间增加了代理对象，可能会造成请求的处理速度变慢。UML结构图如下：
代理模式详情：Java设计模式之结构型：代理模式
策略模式
将类中经常改变或者可能改变的部分提取为作为一个抽象策略接口类，然后在类中包含这个对象的实例，这样类实例在运行时就可以随意调用实现了这个接口的类的行为。
比如定义一系列的算法，把每一个算法封装起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化，这就是策略模式。UML结构图如下：
（1）环境类(Context)：通过 ConcreteStrategy 具体策略类来配置，持有 Strategy 对象并维护对Strategy 对象的引用。可定义一个接口来让 Strategy 访问它的数据。
（2）抽象策略类(Strategy)：定义所有支持的算法的公共接口。 Context使用这个接口来调用某ConcreteStrategy 定义的算法。
（3）具体策略类(ConcreteStrategy)： Strategy 接口的具体算法。
策略模式的优点在于可以动态改变对象的行为；但缺点是会产生很多策略类，并且策略模式的决定权在用户，系统只是提供不同算法的实现，所以客户端必须知道所有的策略类，并自行决定使用哪一个策略类；
策略模式适用用于以下几种场景：
- 应用程序需要实现特定的功能服务，而该程序有多种实现方式使用，所以需要动态地在几种算法中选择一种
- 一个类定义了多种行为算法，并且这些行为在类的操作中以多个条件语句的形式出现，就可以将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
策略模式详情：Java设计模式之行为型：策略模式
模板方法模式
模板方法是基于继承实现的，在抽象父类中声明一个模板方法，并在模板方法中定义算法的执行步骤（即算法骨架）。在模板方法模式中，可以将子类共性的部分放在父类中实现，而特性的部分延迟到子类中实现，只需将特性部分在父类中声明成抽象方法即可，使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤，不同的子类可以以不同的方式来实现这些逻辑。
模板方法模式的优点在于符合“开闭原则”，也能够实现代码复用，将不变的行为转移到父类，去除子类中的重复代码。但是缺点是不同的实现都需要定义一个子类，导致类的个数的增加使得系统更加庞大，设计更加抽象。模板方法模式的UML图如下：
- 抽象类（AbstractClass）：实现了模板方法，定义了算法的骨架。
- 具体类（ConcreteClass)：实现抽象类中的抽象方法，已完成完整的算法。
模板方法详情：Java设计模式之行为型：模板方法模式
享元模式
享元模式通过共享技术有效地支持细粒度、状态变化小的对象复用，当系统中存在有多个相同的对象，那么只共享一份，不必每个都去实例化一个对象，极大地减少系统中对象的数量。比如说一个文本系统，每个字母定一个对象，那么大小写字母一共就是52个，那么就要定义52个对象。如果有一个1M的文本，那么字母是何其的多，如果每个字母都定义一个对象那么内存早就爆了。那么如果要是每个字母都共享一个对象，那么就大大节约了资源。
- （1）Flyweight：抽象享元类，所有具体享元类的超类或者接口，通过这个接口，Flyweight 可以接受并作用于外部专题；
- （2）ConcreteFlyweight：具体享元类。指定内部状态，为内部状态增加存储空间。
- （3）UnsharedConcreteFlyweight：非共享具体享元类。指出那些不需要共享的Flyweight子类。
- （4）FlyweightFactory：享元工厂类，用来创建并管理Flyweight对象，它主要用来确保合理地共享Flyweight。
享元模式的核心是享元工厂类，享元工厂类维护了一个对象存储池，当客户端需要对象时，首先从享元池中获取，如果享元池中存在对象实例则直接返回，如果享元池中不存在，则创建一个新的享元对象实例返回给用户，并在享元池中保存该新增对象，这点有些单例的意思。
工厂类通常会使用集合类型来保存对象，如 HashMap、Hashtable、Vector 等等，在 Java 中，数据库连接池、线程池等都是用享元模式的应用。
享元模式详情：Java设计模式之结构型：享元模式
|
参考： |
