| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -0,0 +1,189 @@ | |||
| 1 | + --- | ||
| 2 | + title: 设计模式学习总结 | ||
| 3 | + date: 2018-07-09 23:05:07 | ||
| 4 | + tags: | ||
| 5 | + - 设计模式 | ||
| 6 | + categories: | ||
| 7 | + - 后端 | ||
| 8 | + - 技术总结 | ||
| 9 | + --- | ||
| 10 | + 设计模式基础学习总结 | ||
| 11 | + 这篇总结主要是基于我之前设计模式基础系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍,可能会有一些错误,还望见谅和指点。谢谢 | ||
| 12 | + | ||
| 13 | + 更多详细内容可以查看我的专栏文章:设计模式学习 | ||
| 14 | + https://blog.csdn.net/a724888/article/category/6780980 | ||
| 15 | + <!-- more --> | ||
| 16 | + | ||
| 17 | + # 设计模式 | ||
| 18 | + | ||
| 19 | + # 创建型模式 | ||
| 20 | + | ||
| 21 | + 创建型模式 | ||
| 22 | + 创建型模式的作用就是创建对象,说到创建一个对象,最熟悉的就是 new 一个对象,然后 set 相关属性。但是,在很多场景下,我们需要给客户端提供更加友好的创建对象的方式,尤其是那种我们定义了类,但是需要提供给其他开发者用的时候。 | ||
| 23 | + | ||
| 24 | + ## 单例 | ||
| 25 | + | ||
| 26 | + 单例模式保证全局的单例类只有一个实例,这样的话使用的时候直接获取即可,比如数据库的一个连接,Spring里的bean,都可以是单例的。 | ||
| 27 | + | ||
| 28 | + 单例模式一般有5种写法。 | ||
| 29 | + | ||
| 30 | + 第一种是饿汉模式,先把单例进行实例化,获取的时候通过静态方法直接获取即可。缺点是类加载后就完成了类的实例化,浪费部分空间。 | ||
| 31 | + | ||
| 32 | + 第二种是饱汉模式,先把单例置为null,然后通过静态方法获取单例时再进行实例化,但是可能有多线程同时进行实例化,会出现并发问题。 | ||
| 33 | + | ||
| 34 | + 第三种是逐步改进的方法,一开始可以用synchronized关键字进行同步,但是开销太大,而后改成使用volatile修饰单例,然后通过一次检查判断单例是否已初始化,如果未初始化就使用synchronized代码块,再次检查单例防止在这期间被初始化,而后才真正进行初始化。 | ||
| 35 | + | ||
| 36 | + 第四种是使用静态内部类来实现,静态内部类只在被使用的时候才进行初始化,所以在内部类中进行单例的实例化,只有用到的时候才会运行实例化代码。然后外部类再通过静态方法返回静态内部类的单例即可。 | ||
| 37 | + | ||
| 38 | + 第五种是枚举类,枚举类的底层实现其实也是内部类。枚举类确保每个类对象在全局是唯一的。所以保证它是单例,这个方法是最简单的。 | ||
| 39 | + | ||
| 40 | + ## 工厂模式 | ||
| 41 | + | ||
| 42 | + 简单工厂一般是用一个工厂创建多个类的实例。 | ||
| 43 | + | ||
| 44 | + 工厂模式一般是指一个工厂服务一个接口,为这个接口的实现类进行实例化 | ||
| 45 | + | ||
| 46 | + 抽象工厂模式是指一个工厂服务于一个产品族,一个产品族可能包含多个接口,接口又会包含多个实现类,通过一个工厂就可以把这些绑定在一起,非常方便。 | ||
| 47 | + | ||
| 48 | + ## 原型模式 | ||
| 49 | + | ||
| 50 | + 一般通过一个实例进行克隆从而获得更多同一原型的实例。使用实例的clone方法即可完成。 | ||
| 51 | + | ||
| 52 | + ## 建造者模式 | ||
| 53 | + | ||
| 54 | + 建造者模式中有一个概念叫做链式调用,链式调用为一个类的实例化提供便利,一般提供系列的方法进行实例化,实际上就是将set方法改造一下,将原本返回为空的set方法改为返回this实例,从而实现链式调用。 | ||
| 55 | + | ||
| 56 | + 建造者模式在此基础上加入了builder方法,提供给外部进行调用,同样使用链式调用来完成参数注入。 | ||
| 57 | + | ||
| 58 | + # 结构型模式 | ||
| 59 | + | ||
| 60 | + | ||
| 61 | + 结构型模式 | ||
| 62 | + 前面创建型模式介绍了创建对象的一些设计模式,这节介绍的结构型模式旨在通过改变代码结构来达到解耦的目的,使得我们的代码容易维护和扩展。 | ||
| 63 | + | ||
| 64 | + ## 桥接模式 | ||
| 65 | + | ||
| 66 | + 有点复杂。建议参考原文 | ||
| 67 | + | ||
| 68 | + ## 适配器模式 | ||
| 69 | + | ||
| 70 | + 适配器模式用于将两个不同的类进行适配。 | ||
| 71 | + | ||
| 72 | + 适配器模式和代理模式的异同 | ||
| 73 | + | ||
| 74 | + 比较这两种模式,其实是比较对象适配器模式和代理模式,在代码结构上, | ||
| 75 | + 它们很相似,都需要一个具体的实现类的实例。 | ||
| 76 | + 但是它们的目的不一样,代理模式做的是增强原方法的活; | ||
| 77 | + 适配器做的是适配的活,为的是提供“把鸡包装成鸭,然后当做鸭来使用”, | ||
| 78 | + 而鸡和鸭它们之间原本没有继承关系。 | ||
| 79 | + | ||
| 80 | + 适配器模式可以分为类适配器,对象适配器等。 | ||
| 81 | + | ||
| 82 | + 类适配器通过继承父类就可以把自己适配成父类了。 | ||
| 83 | + 而对象适配器则需要把对象传入另一个对象的构造方法中,以便进行包装。 | ||
| 84 | + | ||
| 85 | + ## 享元模式 | ||
| 86 | + | ||
| 87 | + / 享元模式的核心在于享元工厂类, | ||
| 88 | + // 享元工厂类的作用在于提供一个用于存储享元对象的享元池, | ||
| 89 | + // 用户需要对象时,首先从享元池中获取, | ||
| 90 | + // 如果享元池中不存在,则创建一个新的享元对象返回给用户, | ||
| 91 | + // 在享元池中保存该新增对象。 | ||
| 92 | + | ||
| 93 | + //享元模式 | ||
| 94 | + // 英文是 Flyweight Pattern,不知道是谁最先翻译的这个词,感觉这翻译真的不好理解,我们试着强行关联起来吧。Flyweight 是轻量级的意思,享元分开来说就是 共享 元器件,也就是复用已经生成的对象,这种做法当然也就是轻量级的了。 | ||
| 95 | + // | ||
| 96 | + // 复用对象最简单的方式是,用一个 HashMap 来存放每次新生成的对象。每次需要一个对象的时候,先到 HashMap 中看看有没有,如果没有,再生成新的对象,然后将这个对象放入 HashMap 中。 | ||
| 97 | + // | ||
| 98 | + // 这种简单的代码我就不演示了。 | ||
| 99 | + | ||
| 100 | + ## 代理模式 | ||
| 101 | + | ||
| 102 | + // 我们发现没有,代理模式说白了就是做 “方法包装” 或做 “方法增强”。 | ||
| 103 | + // 在面向切面编程中,算了还是不要吹捧这个名词了,在 AOP 中, | ||
| 104 | + // 其实就是动态代理的过程。比如 Spring 中, | ||
| 105 | + // 我们自己不定义代理类,但是 Spring 会帮我们动态来定义代理, | ||
| 106 | + // 然后把我们定义在 @Before、@After、@Around 中的代码逻辑动态添加到代理中。 | ||
| 107 | + | ||
| 108 | + ## 外观模式 | ||
| 109 | + | ||
| 110 | + 外观模式一般封装具体的实现细节,为用户提供一个更加简单的接口。 | ||
| 111 | + | ||
| 112 | + 通过一个方法调用就可以获取需要的内容。 | ||
| 113 | + | ||
| 114 | + ## 组合模式 | ||
| 115 | + | ||
| 116 | + //组合模式用于表示具有层次结构的数据,使得我们对单个对象和组合对象的访问具有一致性。 | ||
| 117 | + | ||
| 118 | + //直接看一个例子吧,每个员工都有姓名、部门、薪水这些属性, | ||
| 119 | + // 同时还有下属员工集合(虽然可能集合为空), | ||
| 120 | + // 而下属员工和自己的结构是一样的, | ||
| 121 | + // 也有姓名、部门这些属性, | ||
| 122 | + // 同时也有他们的下属员工集合。 | ||
| 123 | + | ||
| 124 | + class Employee { | ||
| 125 | + private String name; | ||
| 126 | + private String dept; | ||
| 127 | + private int salary; | ||
| 128 | + private List<Employee> subordinates; // 下属 | ||
| 129 | + } | ||
| 130 | + | ||
| 131 | + ## 装饰者模式 | ||
| 132 | + | ||
| 133 | + ## 装饰者 | ||
| 134 | + 装饰者模式把每个增强类都继承最高级父类。然后需要功能增强时把类实例传入增强类即可,然后增强类在使用时就可以增强原有类的功能了。 | ||
| 135 | + | ||
| 136 | + 和代理模式不同的是,装饰者模式每个装饰类都继承父类,并且可以进行多级封装。 | ||
| 137 | + | ||
| 138 | + | ||
| 139 | + # 行为型模式 | ||
| 140 | + | ||
| 141 | + 行为型模式 | ||
| 142 | + 行为型模式关注的是各个类之间的相互作用,将职责划分清楚,使得我们的代码更加地清晰。 | ||
| 143 | + | ||
| 144 | + ## 策略模式 | ||
| 145 | + | ||
| 146 | + 策略模式一般把一个策略作为一个类,并且在需要指定策略的时候传入实例,于是我们可以在需要使用算法的地方传入指定算法。 | ||
| 147 | + | ||
| 148 | + ## 命令模式 | ||
| 149 | + | ||
| 150 | + 命令模式一般分为命令发起者,命令以及命令接受者三个角色。 | ||
| 151 | + | ||
| 152 | + 命令发起者在使用时需要注入命令实例。然后执行命令调用。 | ||
| 153 | + | ||
| 154 | + 命令调用实际上会调用命令接收者的方法进行实际调用。 | ||
| 155 | + | ||
| 156 | + 比如遥控器按钮相当于一条命令,点击按钮时命令运行,自动调用电视机提供的方法即可。 | ||
| 157 | + | ||
| 158 | + ## 模板方法模式 | ||
| 159 | + | ||
| 160 | + 模板方法一般指提供了一个方法模板,并且其中有部分实现类和部分抽象类,并且规定了执行顺序。 | ||
| 161 | + | ||
| 162 | + 实现类是模板提供好的方法。而抽象类则需要用户自行实现。 | ||
| 163 | + | ||
| 164 | + 模板方法规定了一个模板中方法的执行顺序,非常适合一些开发框架,于是模板方法也广泛运用在开源框架中。 | ||
| 165 | + | ||
| 166 | + ## 状态模式 | ||
| 167 | + | ||
| 168 | + 少见。 | ||
| 169 | + | ||
| 170 | + ## 观察者模式和事件监听机制 | ||
| 171 | + | ||
| 172 | + 观察者模式一般用于订阅者和消息发布者之间的数据订阅。 | ||
| 173 | + | ||
| 174 | + 一般分为观察者和主题,观察者订阅主题,把实例注册到主题维护的观察者列表上。 | ||
| 175 | + | ||
| 176 | + 而主题更新数据时自动把数据推给观察者或者通知观察者数据已经更新。 | ||
| 177 | + | ||
| 178 | + 但是由于这样的方式消息推送耦合关系比较紧。并且很难在不打开数据的情况下知道数据类型是什么。 | ||
| 179 | + | ||
| 180 | + 知道后来为了使数据格式更加灵活,使用了事件和事件监听器的模式,事件包装的事件类型和事件数据,从主题和观察者中解耦。 | ||
| 181 | + | ||
| 182 | + 主题当事件发生时,触发该事件的所有监听器,把该事件通过监听器列表发给每个监听器,监听得到事件以后,首先根据自己支持处理的事件类型中找到对应的事件处理器,再用处理器处理对应事件。 | ||
| 183 | + | ||
| 184 | + | ||
| 185 | + | ||
| 186 | + ## 责任链模式 | ||
| 187 | + | ||
| 188 | + 责任链通常需要先建立一个单向链表,然后调用方只需要调用头部节点就可以了,后面会自动流转下去。比如流程审批就是一个很好的例子,只要终端用户提交申请,根据申请的内容信息,自动建立一条责任链,然后就可以开始流转了。 | ||
| 189 | + | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments