设计模式的6大原则：源
1、单一职责原则 -----每个类应该实现单一的职责
2、里氏替换原则------继承复用，增加新的行为
3、依赖倒转原则------依赖抽象而不依赖具体
4、接口隔离原则------使用多个隔离的接口
5、迪米特法则--------只与直接的朋友通信，减少依赖
6、合成复用原则------使用合成/聚合的方式，而不是使用继承

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式，共七种：适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

代理模式

代理模式的定义：
代理是设计模式的一种，代理类为委托类提供消息预处理，消息转发，事后消息处理等功能。
Java中的代理按照代理类生成时机不同又分为静态代理和动态代理，代理分为三种角色：

1、代理类(ProxySubject)
2、委托类(RealSubject)
3、接口(Subject)

静态代理
静态代理代理类在编译期就生成，而动态代理代理类则是在Java运行时动态生成，静态代理代码冗余大，一但需要修改接口，代理类和委托类都需要修改。

举个例子
接口(Subject)：

interface HelloService {void sayHello();
}

委托类：

class HelloServiceImpl implements HelloService {@Overridepublic void sayHello() {System.out.println("Hello World!");}
}

代理类：

class HelloServiceProxy implements HelloService {private HelloService helloService;public HelloServiceProxy(HelloService helloService) {this.helloService = helloService;}@Overridepublic void sayHello() {System.out.println("Before say hello...");helloService.sayHello();System.out.println("After say hello...");}
}

测试类：

public class HelloServiceProxyTest {public static void main(String[] args) {HelloService helloService = new HelloServiceImpl();HelloServiceProxy proxy = new HelloServiceProxy(helloService);proxy.sayHello();}
}

输出结果：
Before say hello...
Hello World!
After say hello...

动态代理
Java中的动态代理代理类在JVM运行时动态生成，依靠反射来实现，委托类需要实现接口。
Java动态代理主要涉及到两个类：java.lang.reflect.Proxy和java.lang.reflect.InvocationHandler。代理类需要实现InvocationHandler接口或者创建匿名内部类。

接口(Subject)：

interface HelloService {void sayHello();
}

委托类：

class HelloServiceImpl implements HelloService {@Overridepublic void sayHello() {System.out.println("Hello World!");}
}

动态代理类：

class HelloServiceDynamicProxy {private HelloService helloService;public HelloServiceDynamicProxy(HelloService helloService) {this.helloService = helloService;}public Object getProxyInstance() {return Proxy.newProxyInstance(helloService.getClass().getClassLoader(), helloService.getClass().getInterfaces(), new InvocationHandler() {@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {System.out.println("Before say hello...");Object ret = method.invoke(helloService, args);System.out.println("After say hello...");return ret;}});}
}

测试类：

public class HelloServieDynamicProxyTest {public static void main(String[] args){HelloService helloService = new HelloServiceImpl();HelloService dynamicProxy = (HelloService) new HelloServiceDynamicProxy(helloService).getProxyInstance();dynamicProxy.sayHello();}
}

输出结果
Before say hello...
Hello World!
After say hello...

单例

//饿汉式 类一加载进内存就创建好了对象
class Singleton {  private Singleton() {} private static Singleton s = new Singleton(); public static Singleton getInstance() {  return s; } }

懒汉式是类加载进内存的时候，对象还没有存在，要使用该对象的时候再new出来，*懒汉式是延迟加载，如果多个线程同时操作懒汉式时就有可能出现线程安全问题为解决饱汉式的线程安全问题，解决线程安全问题可以加同步来解决。但是加了同步之后，每一次都要比较锁，效率就变慢了。

//懒汉式
class Single { private Single() {} private static Single s = null ;  public static Single getInstance() { public static synchronized Single getInstance() {    //加锁同步安全if (s == null) {  s = new Single();    }         return s;
} }

通过双重判断来提高程序效率，所谓“双重检查加锁”机制，指的是：

//双重检查
class Single { private Single() {} private volatile static Single s = null;  public static Single getInstance() {//先检查实例是否存在，如果不存在才进入下面的同步块if (s == null) {  //同步快，线程安全创建实例synchronized (Singleton.class) {//再次检查实例是否存在，如果不存在才真正的创建实例if(s == null){s = new Single();    }}}         return s;
} }

1、第一个条件是说，如果实例创建了，那就不需要同步了，直接返回就好了。  if (singleton== null)  {
2、不然，我们就开始同步线程。                               synchronized (Singleton.class) {
3、第二个条件是说，如果被同步的线程中有一个线程创建了对象，那么别的线程就不用再创建了。  if (singleton== null)  {

问题主要在于singleton = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情
1、给 singleton 分配内存
2、调用 Singleton 的构造函数来初始化成员变量，形成实例
3、将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错

对此，我们只需要把singleton声明成 volatile 就可以了，有两个功用：

1）这个变量不会在多个线程中存在复本，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量

2）这个关键字会禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。

静态内部类：

支持多线程-懒汉式
//特点：利用静态内部类（只有在出现它的引用时才被加载），完成懒加载class Single{private Single(){}public static Single getInstance(){return SingleHolder.instance;}private static class SingleHolder{public static Single instance = new Single();}
}

观察者模式

/*** 抽象观察者类*/
public interface IObserver {void update(String message);
}/*** 抽象主题类*/
public interface ISubject {void add(IObserver observer);void remove(IObserver observer);void notify(String message);
}/*** 具体观察者类*/
public class Observer implements IObserver {@Overridepublic void update(String message) {System.out.println(message);}
}/*** 具体主题类*/
public class Subject implements ISubject {List<IObserver> list = new ArrayList<>();@Overridepublic void add(IObserver observer) {list.add(observer);}@Overridepublic void remove(IObserver observer) {list.remove(observer);}@Overridepublic void notify(String message) {for(IObserver observer: list){observer.update(message);}}
}

模式分析

抛去模式中的接口类，就剩下了主题和观察者，这个模式的发生就是基于主题的变更与对观察者的通知。

这个模式在我的 helper 工具包中也有使用，就是基于对系统服务的监听，发现变化后，对订阅此变化的观察者们发出通知，并由观察者自己作出相应的动作。

缺点：

一个主题存在多个观察者，而通知的方式是通过轮询，这样的通知会有一定的时间消耗。
如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。

适配器模式

类适配器

public interface MP4{void play();
}public class MP4Player implements MP4{public void play(){// doSomething}
}public interface Player{void action();
}public class Adapter extends MP4Player implements Player{public void action(){play();}
}

对象适配器

public class PlayerAdapter implements Player{public MP4 mp4;public PlayerAdapter (MP4 mp4){this.mp4 = mp4;}     public void action(){if(mp4!= null){mp4.play();}}
}

模式分析

适配器模式简单来说就是为两个互不兼容的两者提供了合作的桥梁。

想一想我们在Android中使用的RecyclerView中为了进行数据的适配是不是都会加上一个Adapter，因为我们从网络获取的数据Bean是无法直接和XML文件中的每个View需要填充的数据项进行对应的。而适配器就是将两者进行了沟通协作。

类适配器模式和对象适配器模式的区别是什么？

类适配器使用了继承的方式来完成、对象适配器使用了依赖的关系来完成任务。拿代码来说的话就是类适配器继承了MP4Player，而对象适配器依赖就是MP4这个接口类的使用。

缺点

类适配器模式 对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口。
对象适配器模式 与类适配器模式相比，要想置换适配者类的方法就不容易。如果一定要置换掉适配者类的一个或多个方法，就只好先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

策略模式

方案
把一个类中经常改变或者将来可能改变的部分提取出来，作为一个接口，然后在类中包含这个对象的实例，这样类的实例在运行时就可以随意调用实现了这个接口的类的行为。

适用情况
许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。

优点
1、可以动态的改变对象的行为
缺点
1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类
2、策略模式将造成产生很多策略类

组成
抽象策略类(Strategy):定义所有支持的算法的公共接口
具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。
环境类(Context): 使用这个接口来调用某ConcreteStrategy定义的算法，通过Context来连接起Strategy和ConcreteStrategy桥梁。

举个栗子：
场景如下，刘备要到江东娶老婆了，走之前诸葛亮给赵云三个锦囊妙计，说是按天机拆开能解决棘手问题。场景中出现三个要素：三个妙计（具体策略类）、一个锦囊（环境类）、赵云（调用者）

抽象策略类（Strategy）

public interface Strategy {public void operate();
}

三个实现类（ConcreteStrategy）

妙计一：初到吴国

public class IntoCountry implements Strategy {@Overridepublic void operate() {System.out.println("找乔国老帮忙，让吴国太给孙权施加压力，使孙权不能杀刘备");}
}

妙计二：求吴国太开绿灯放行

public class GivenGreenLight implements Strategy {@Overridepublic void operate() {System.out.println("求吴国太开个绿灯，放行");}
}

妙计三：孙夫人断后，挡住追兵

public class BlockEnemy implements Strategy {@Overridepublic void operate() {System.out.println("孙夫人断后，挡住追兵");}
}

环境类（Context)

public class Context {private Strategy strategy;//构造函数，要你使用哪个妙计public Context(Strategy strategy){this.strategy = strategy;}public void operate(){this.strategy.operate();}
}

下面就是使用的情况了

public class Zhaoyun {public static void main(String[] args) {System.out.println("----------刚到吴国使用第一个锦囊---------------");Context IntoCountry = new Context(new IntoCountry());IntoCountry.operate();System.out.println("----------刘备乐不思蜀使用第二个锦囊---------------");Context GivenGreenLight = new Context(new GivenGreenLight());GivenGreenLight.operate();System.out.println("----------孙权的追兵来了，使用第三个锦囊---------------");Context BlockEnemy = new Context(new BlockEnemy());BlockEnemy.operate();}
}

以上就是策略模式，多种不同解决方案动态切换，起到改变对象行为的效果。

建造者模式（Builder Pattern）

UML类图 & 组成

模式讲解：

1、指挥者（Director）直接和客户（Client）进行需求沟通；
2、沟通后指挥者将客户创建产品的需求划分为各个部件的建造请求（Builder）；
3、将各个部件的建造请求委派到具体的建造者（ConcreteBuilder）；
4、各个具体建造者负责进行产品部件的构建；
5、最终构建成具体产品（Product）

举个栗子：小成希望去电脑城买一台组装的台式主机
过程：
1、电脑城老板（Diretor）和小成（Client）进行需求沟通（买来打游戏？学习？看片？）
2、了解需求后，电脑城老板将小成需要的主机划分为各个部件（Builder）的建造请求（CPU、主板blabla）
3、指挥装机人员（ConcreteBuilder）去构建组件；
4、将组件组装起来成小成需要的电脑（Product）

使用步骤
步骤1： 定义组装的过程（Builder）：组装电脑的过程


public  abstract class Builder {  //第一步：装CPU
//声明为抽象方法，具体由子类实现 public abstract void  BuildCPU()；//第二步：装主板
//声明为抽象方法，具体由子类实现 public abstract void BuildMainboard（）；//第三步：装硬盘
//声明为抽象方法，具体由子类实现 public abstract void BuildHD（）；//返回产品的方法：获得组装好的电脑public abstract Computer GetComputer（）；
}

步骤2： 电脑城老板委派任务给装机人员（Director）

public class Director{//指挥装机人员组装电脑public void Construct(Builder builder){builder. BuildCPU();builder.BuildMainboard（）;builder. BuildHD（）;}}

步骤3：创建具体的建造者（ConcreteBuilder）:装机人员

//装机人员1public class ConcreteBuilder extend  Builder{//创建产品实例Computer computer = new Computer();//组装产品@Overridepublic void  BuildCPU(){  computer.Add("组装CPU")}  @Overridepublic void  BuildMainboard（）{  computer.Add("组装主板")}  @Overridepublic void  BuildHD（）{  computer.Add("组装主板")}  //返回组装成功的电脑@Overridepublic  Computer GetComputer（）{  return computer}
}

步骤4：定义具体产品类（Product）：电脑

public class Computer{//电脑组件的集合private List<String> parts = new ArrayList<String>()；//用于将组件组装到电脑里public void Add(String part){parts.add(part);
}public void Show(){for (int i = 0;i<parts.size();i++){    System.out.println(“组件”+parts.get(i)+“装好了”);}System.out.println(“电脑组装完成，请验收”); }}

步骤5：客户端调用-小成到电脑城找老板买电脑


public class Builder Pattern{public static void main(String[] args){//逛了很久终于发现一家合适的电脑店
//找到该店的老板和装机人员Director director = new Director();Builder builder = new ConcreteBuilder();//沟通需求后，老板叫装机人员去装电脑
director.Construct(builder);//装完后，组装人员搬来组装好的电脑
Computer computer = builder.GetComputer();
//组装人员展示电脑给小成看
computer.Show()；}}

结果输出

组件CUP装好了
组件主板装好了
组件硬盘装好了
电脑组装完成，请验收

优点
1、易于解耦
将产品本身与产品创建过程进行解耦，得到不同的产品。也就说细节依赖抽象。

2、易于精确控制对象的创建
将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰

3、易于拓展
增加新的具体建造者无需修改原有类库的代码，易于拓展，符合“开闭原则“。
每一个具体建造者都相对独立，而与其他的具体建造者无关

缺点
1、如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
2、如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

应用场景
1、需要生成的产品对象有复杂的内部结构，这些产品对象具备共性；
2、隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

23种设计模式之几种常用模式相关推荐

Unity实现：23种设计模式、《游戏编程模式》
目录一.23种设计模式在Unity实现 Creational Patterns 创建型模式(5种) 工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式 Structural Patterns ...
JavaScript 23 种设计模式之 4 抽象工厂模式
JavaScript 23 种设计模式之 4 抽象工厂模式概念与特点结构与实现应用场景应用实例总结概念与特点概念: 提供一组相关或相互依赖对象的接口.抽象工厂模式是工厂方法模式的升级版, ...
23种设计模式（第二章创建者模式5种）
第二章创建者模式单例模式单例模式有 3 个特点: 单例类只有一个实例对象: 该单例对象必须由单例类自行创建: 单例类对外提供一个访问该单例的全局访问点. 单例模式的实现单例设计模式分类两种: ...
23种设计模式（2）-工厂模式
定义: 工厂模式是 Java 中最常用的设计模式之一.这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式. 工厂模式主要是为创建对象提供过渡接口,以便将创建对象的具体过程屏蔽隔离起来,达 ...
23种设计模式 -----Day01：简单工厂模式
目录前言 1.设计模式(Design pattern)定义 2.为什么要使用设计模式(使用设计模式的意义) 3.设计原则 a.单一职责原则 b.开放封闭原则 c.里氏代换原则 d.迪米特法则 e.依 ...
23种设计模式之单例模式、工厂模式、原型模式、建造者模式
系列文章目录第一章:程序设计原则-单一职责.接口隔离.依赖倒置.里式替换第二章:程序设计原则-开闭原则.迪米特法则.合成复用原则文章目录系列文章目录一.设计模式简单介绍 1.1.什么是设计模 ...
23种设计模式学习记录之代理模式
想说的话: 在大学的时候曾经学过这23种设计模式,但是那时没啥编程经验,糊里糊涂过了一遍,没多久就忘记了,工作之后将精力主要集中在学习新技术上,比如springboot,cloud,docker,vu ...
23种设计模式（十一）外观模式（阁瑞钛伦特软件-九耶实训）
常说的设计模式是23种设计模式,分为3大类: 创建型模式5种:工厂方法.抽象工厂.单例.建造者.原型结构型模式7种:适配器.代理.桥接.装饰者.外观.享元.组合行为型模式11种:模板方法.解释器. ...
【23种设计模式专题】二工厂模式
程序猿学社的GitHub,欢迎Star github技术专题本文已记录到github 文章目录前言小故事传统方式简单工厂(第一种) 工厂方法模式(第二种) 抽象工厂模式(第三种) 使用工厂方 ...

23种设计模式之几种常用模式

代理模式

单例

观察者模式

模式分析

适配器模式

模式分析

策略模式

建造者模式（Builder Pattern）

23种设计模式之几种常用模式相关推荐

最新文章

热门文章