原文链接：
设计模式的作用
工欲善其事,必先利其器.若想写好代码，在千万行代码中你的系统依旧结构逻辑清晰,高度可拓展,高度的可用和健壮,你可能就需要好好学习设计模式了,其次你是否还会因为看各种源码而头疼，看不懂，太复杂，理不断，剪还乱.学习了设计模式,我们可能对各种框架源码的设计思想会有一些全新的认识.正所谓知其然，知其所以然然，知其所必然.总而言之,设计模式是做好程序员的必经之路.
什么是设计模式
一句话概括,设计模式是思想,针对各种复杂的业务场景而总结的一种规范和完美的业务功能的实现.(通俗的说就是前人针对各种复杂业务场景实现的方式和思想)
为什么要用设计模式
仁者见仁智者见智,我谈谈我为什么用设计模式,我曾经在创业公司单独开发过一款APP的后台,在写了半年之后,我完成了很多功能,APP的开发是不确定性的,需求时常改动,后来的的代码我自己看不懂了,改的太乱了,各种功能的拓展,兼容,当时就是随性而写,实现功能便好,后来才发现代码结构设计的重要性,之后来到某500强企业,看到大型的大数据管理平台,更加证实了我的这一点,大型系统的构建是必须遵照设计模式去写的,不然对于一个G的代码维护谁能理得清晰呢?
学好设计模式的前提
学好设计模式就必须先了解一些些代码的设计规则
- 开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现
一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的
效果，我们需要使用接口和抽象类.
- 里氏代换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原
则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当衍生类可以
替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增
加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而
基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
- 依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
- 接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，
从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。
所以上文中多次出现：降低依赖，降低耦合。
- 迪米特法则（最少知道原则）（Demeter Principle）为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能
模块相对独立。
- 合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。
常用的设计模式
- 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
- 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
- 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
## 详解特别常用的设计模式
每个设计模式都不能去死记硬背，寻找一些场景去理解学习。接下来也会使用源码和博客讲解结合,寻找一些业务场景去讲解每种设计模式的设计思想.
==源码的地址详见==：https://github.com/17302102404/deisgnPattern
### 工厂模式
- 核心思想和业务目的
生成一个我需要的实例，我不需要知道生产的过程。我只要按你的要求你给我一个实例就好。这个设计的合理和细节的处理在于设计。
- 实现方式
1. 简单工厂模式 (模式简单，可拓展性较低，不可配置，植入)
```
Class MilkFactory //牛奶工厂
get milk(String name){
if(name.equals("yinli")){
new Yinli();
}else if("mengniu"){
new Mengniu();
}..........
}
```
2. 抽象工厂模式(可拓展，用户体验好，提供选择，所有的结果右选择决定，用户不要需要输入，提交代码的健壮性，抽象类的抽象方法，统一相同特性，易于管理)
```
abstract Class AbstractFactory{
commons()//公共需要的方法
}
第二层：牛奶工厂
abstract Class MilkFactory() extends AbstractFactory{
milkcomons() //牛奶共同特征方法
abstract fun()//抽象方法
getYinli(){
new YinliFactory();
}
getMengniu（）{
mew MengniuFactory'();
}
...............
}
第三层：品牌牛奶工厂
class MilkFactory extends MilkFactory
```
- 抽象工厂相对简单工厂的优势：
以这种层次结构清晰，将一个复杂的流程结构化，层次化，代码的维护性和健壮性得到提升。最重要的是利于拓展.工厂模式时创造模式：解决用户和产品之间的关系，对于用户并不知道有哪些产品，但我们可提供选择，例如MilkFactory中的get..... 方法即可知道有哪些品牌的牛奶，相对于简单工厂不用输入参数，第二可拓展性，新增一个品牌牛奶，只有他们建立一个工厂，然后在我们这注册一下，用户就可以get..
，方式对比之前未发生改变，这就是抽象的工厂模式.Spring的Beanfactory就是使用的抽象工厂模式。
### 单例模式
- 核心思想和业务目的
单例模式通常的说就是系统在整个运行过程中一个类只允许有一个实例(整个过程只new了一次)
- 业务实现的难题
在多线程并发情况下往往需要一些对象是单例的，如何保证多线程情况下的单例呢？
比如：某个系统的环境配置，环境变量类，这些只存在一份的都应该是单例的，在系统运行时候就一直应该保证唯一，在系统运行过程中，每个线程拿到的都是一样的实例。
- 实现方式（饿汉式，懒汉式，注册登记式，枚举式）
1. 饿汉式：在实例使用之前，不管你用不用，我都先new出来再说，避免了线程安全问题，对象加载时已创建静态的对象：
```
Class Hungry {
private Static Hungry hungry = new Hungry();
public Static Hungry getInstance(){
return hungry ;
}
}
```
2. 懒汉式：默认加载时候不实例化，在使用的使用才进行实例化（延时加载）
- 存在线程程安全懒汉式
```
Class Lazy {
private Static Lazy lazy = null ；
public Static Lazy getInstance(){
if(lazy ==null){
lazy = new hungry();
}
return lazy;
}
}
```
- 线程安全，但性能受限的做法
在上述的方法中加上synchronized 同步锁即可
```
Class Lazy {
private Static Lazy lazy = null ；
public synchronized Static Lazy getInstance(){
if(lazy ==null){
lazy = new hungry();
}
return lazy;
}
}
```
- 以上两种在实际应用场景中均不建议使用，如果要用懒汉式，建议使用双重锁
观察可知，但对于第二种做法可以将锁的粒度减小，针对多线程，并非多需要加锁，我们需要单例，只需要针对hungry对象为null的线程并非的时候才需要加锁，故优化的写法可以写为
```
Class Lazy {
private Static Lazy lazy = null ；
public Static Lazy getInstance(){
if(lazy ==null){ //针对lazy==null才需要同步
synchronized (Lazy.class) {
if (lazy == null) {
lazy = new hungry();
}
return lazy;
}
```
3. 注册登记式：每使用一次，都往一个固定的容器中国去注册并且使用过的对象进行缓存，下次去取对象的时候，就直接从缓存中取值，以保证每次获取同一个对象。Ioc中的单例模式，就是典型的注册式单例。用map将对象存起来
```
private Object readResolve(){
private static ConcurrentHashMap<String,Object> map = new ConcurrentHashMap();
public static Object getInstance(String name){
if(name == null){
return new RegisterPattern();
}
if(map.get(name) == null) {
map.put("name", new RegisterObject());
}
return map.get("name");
}
}
```
### 原型模式：
- 核心思想和业务目的
原型模式就是实现两个实体模型之间的复制
- 开发场景
spring中的原型模式：scope=“prototype”， 默认是单例模式，也可以是原型模式
业务模型直接的相互转化
1. VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
2. DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。
3. DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
4. PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。
- 实现方式
apache 反射实现
clone() jdk提供的方法
- 注意事项
浅复制和深复制的区别：
- 浅复制：只是最外层的对象不是同一个内存地址，属性对象都同一个内存空间（一般这种复制是不符合业务场景的，一般要求两个对象的完全独立和隔离），其中jdk的clone()默认的是浅复制
- 深度复制：深度复制是复制之后，两个对像的属性对象也完全隔离和独立。可以通过对象序列化和反序列化去实现
### 代理模式
- 核心思想和业务目的
代理模式的思想是有一个对象不会无法做某事，需要另一个对象来代理他做事，所以代理模式一定存在连个对象，代理角色，被代理的角色（目标对象），由被代理角色来做最终的决定，代理角色通常持有被代理角色的引用。最终是目标对象能够完成某个过程。
- 开发场景
AOP典型的实现，中介，黄牛，媒婆，拦截器，专人做专事，自己不想做或者不会做的事给别人来做，增强
- 实现方式
静态代理和动态代理，代理的实现过程，一定有一个代理类和被代理类，动态动态代理一般生产的是代码执行过程中动态的生成一个代理类，本质和静态代理一样，但可拓展确比静态代理提升了太多，我们可以在执行过程中将动态代码类输出文件，反编译便可看出动态代理的过程。
参考github上的代码查看jdk和cglib实现动态代理过程：https://github.com/17302102404/deisgnPattern/tree/master/src/main/java/org/czx/proxypattern
- 动态代理和静态的代理的区别
最大的过程是动态代理是执行过程才会生成代理对象，执行过程会通过代码的重组，编译，jvm加载产生一个代理对象，执行完之后就销毁了。而静态代理是未执行之前就定义好的。动态代理统一代理方法管理，没必要给每个需要代理的对象新建一个代理对象，提高可拓展性。
### 策略模式
- 核心思想和业务目的
给定一些固定的东西去做选择，用户的选择处理一个固定的算法的时候需要用到策略模式，典型的应用场景就是电商的购物支付的流程
- 开发场景
订单支付场景，支付方式很多(微信，支付宝，余额，银行卡等)
支付的方式里面的流程都是固定流程，需单独拆分，对于用户就是下单，选择支付。
订单支付需要做一个策略。
- 实现方式
订单支付流程代码设计详见：https://github.com/17302102404/deisgnPattern/tree/master/src/main/java/org/czx/strategypattern
### 模板方法模式
- 核心思想和业务目的
对于一些具体的业务流程，必须安装某个流程去执行，但是中间的某个过程可以进行自定义。如spring源码中的jdbctemplate，其中一些代码设计实现了解耦，dao层如何不用继承而是定义属性就能实现。
- 实现方式
对于一个抽象的方法引入一个接口，要想使用某个方法你可以自定义接口的实现类，从而实现了可以自定义某个模板流程的方法。
具体可以查看JDBCTemplate中的模板类，其中RowMapper就是实现查询自定义结果的接口。
### 观察者模式
- 核心思想和业务目的
观察者模式本质其实就是观察者和被观察者之间能互动，就是被观察者某个状态发生变化，观察者去触发某个动作，典型的业务场景就是发布订阅，zookeeper的监控，监听器、日志收集、短信通知、邮件通知
- 实现方式
对象的设计
1. Subject（被观察的对象接口）:规定ConcreteSubject的统一接口 ; 每个Subject可以有多个Observer
1. ConcreteSubject（具体被观察对象）:维护对所有具体观察者的引用的列表 ；–状态发生变化时会发送通知给所有注册的观察者
1. Observer（观察者接口）:规定ConcreteObserver的统一接口；定义了一个update()方法，在被观察对象状态改变时会被调用
1. ConcreteObserver（具体观察者）:维护一个对ConcreteSubject的引用；特定状态与ConcreteSubject同步； 实现Observer接口，update()方法的作用：一旦检测到Subject有变动，就更新信息
具体代码详见:https://github.com/17302102404/deisgnPattern/tree/master/src/main/java/org/czx/observerpattern
### 适配器模式和装饰器模式
- 说明
这两种模式差不多，其中装饰器模式实际上一种特殊的适配器模式，所谓的适配器模式，适配器其实就是一个转换，在很多场景中我们写代码需要兼容一些旧的功能，
我们就可以使用适配器模式可以做一些业务上的转换。
可以说适配器其实是一种思想，转换的逻辑也要因具体业务而定。装饰器模式就是为了某个实现类在不修改原始类的基础上进行动态的覆盖或者增加方法。
但是的保持跟原有类的层级关系，比如流的那块高级流其实就是对低级流的增强。
- 实现方式
实现适配器模式的过程无非也是继承和重组
实现装饰器的过程就是将旧的作为一个成员变量
```
class A{
public void run(){
..............
}
public void go(){
}
}
//B类拥有A所有的功能，并且B对A进行的拓展
class B{
private A a;
public B(A a){
this.a=a;
}
public void run(){
this.a.run();
}
public void go(){
this.a.go();
}
//public void quickrun(){
...............
}
}
```
### 委派模式
委派模式不在23种设计模式中，但却是写代码的一种很好的设计模式
- 设计思想和应用场景
委派模式就好比一个管理者，有上级有下属，做好中间的协同工作。就像注册中心
管理分发请求。举例说明：
spring 中的DispatchServlet就是一个委派者。
浏览器请求 ，dispatchServlet转发 ，指定class 方法
- 优势(servlet和spring mvc转发对比)
1. 传统的httpservlet的过程:
浏览器请求httprequest直接根据path的匹配去找，相当的麻烦
```
web.xml 配一堆配置
<servlet>
<servlet-name>LoginServlet</servlet-name>
<servlet-class>com.breeze.servlet.LoginServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>LoginServlet</servlet-name> 与上面的 <servlet-name> 要一致
<url-pattern>/servlet/LoginServlet</url-pattern>
</servlet-mapping>
```
2. 使用DispatchServlet进行一个服务管理，Dispatchserver会有action的对应信息管理，httprequest
只需要和distpatchServelet交付任务。Distch会根据自己的策略选择正确的action去执行。
157
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
