23种java版设计模式源码案例.zip

# 设计模式 [](https://travis-ci.com/)  ## 0.目录 - 创建型模式(creational) * 简单工厂(simplefactory) * 动态工厂(dynamic) * 抽象工厂(abstract) * 单例模式(singleton) * 建造者模式(builder) * 原型模式(prototype) - 结构型模式(structure) * 适配器模式(adaptor) * 桥接模式(bridge) * 组合模式(composite) * 装饰器模式(decorate) * 外观模式(facecade) * 享元模式(flyweight) * 代理模式(proxy) - 行为型模式(behaviour) * 责任链模式(chainrespon) * 命令模式(commond) * 解释器模式(interpreter) * 迭代器模式(iterator) * 中介者模式(mediator) * 备忘录模式(memento) * 观察者模式(observer) * 状态模式(state) * 空对象模式(null object) * 策略模式(strategy) * 模板模式(template) * 访问者模式(visitor) ## 1.介绍 ### 1.1 创建型模式(creational) > 简单工厂模式/静态工厂模式(factory/simplefactory) ``` 优点： 1.将创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建，实现了解耦 2.把初始化实例时的工作放到工厂里进行，使代码更容易维护。 更符合面向对象的原则 & 面向接口编程，而不是面向实现编程 3.通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的产品类，在一定程度下提高了灵活性 缺点： 1.工厂类集中了所有实例(产品)的创建逻辑，一旦这个工厂不能正常工作，整个系统都会受到影响； 2.违背“开放 - 关闭原则”，一旦添加新产品就不得不修改工厂类的逻辑，这样就会造成工厂逻辑过于复杂。 3.简单工厂模式由于使用了静态工厂方法，静态方法不能被继承和重写，会造成工厂角色无法形成基于继承的等级结构。 使用场景：客户如果只知道传入工厂类的参数，对于如何创建对象的逻辑不关心时； 当工厂类负责创建的对象(具体产品)比较少时 ``` > 工厂模式(factory/dynamic) 让实例化推迟到子类 ``` 优点： 1.一个调用者想创建一个对象，只要知道其名称就可以了。 2.扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3.屏蔽产品的具体实现，调用者只关心产品的接口。 缺点： 1每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。 使用场景： 1.日志记录器：记录可能记录到本地硬盘.系统事件.远程服务器等，用户可以选择记录日志到什么地方。 2.数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3.设计一个连接服务器的框架，需要三个协议，"POP3"."IMAP"."HTTP"，可以把这三个作为产品类，共同实现一个接口。 注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。 ``` > 抽象工厂(factory/abstract) **将压力分配到具体的工厂** ``` 优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。 缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码 ``` > 单例模式(singleton) ``` 优点： 1.在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例(比如管理学院首页页面缓存)。 2.避免对资源的多重占用(比如写文件操作)。 缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。 使用场景： 1.要求生产唯一序列号。 2.WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。 3.创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。 注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化 ``` > 建造者模式(builder) **相比工厂模式更加关注构建的细节** lombok @Builder使用的就是建造者模式 ``` 优点： 1.建造者独立，易扩展。 2.便于控制细节风险。 缺点： 1.产品必须有共同点，范围有限制。 2.如内部变化复杂，会有很多的建造类。 使用场景： 1.需要生成的对象具有复杂的内部结构。 2.需要生成的对象内部属性本身相互依赖。 注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序 ``` > 原型模式(prototype) ``` 优点： 1.性能提高。 2.逃避构造函数的约束。 缺点： 1.配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持序列化的间接对象，或者引用含有循环结构的时候。 使用场景： 1.资源优化场景。 2.类初始化需要消化非常多的资源，这个资源包括数据.硬件资源等。 3.性能和安全要求的场景。 4.通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5.一个对象多个修改者的场景。 6.一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 7.在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。 注意事项：与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。 ``` ### 1.2 结构型模式(structure) #### 总结 ``` 适配器:接口兼容问题 桥接:桥接属性，构建不同维度的对象 组合:忽略整体-细节部分，创建层次分明的对象 装饰:动态地未已有接口添加新行为 外观:一键啥啥啥 享元:共享对象的部分相似特效，优化内存，高度重用 代理:让自己的亲兄弟为自己办事 ``` > 适配器模式(adaptor) ``` 优点： 1.可以让任何两个没有关联的类一起运行。 2.提高了类的复用。 3.增加了类的透明度。 4.灵活性好。 使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。 注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题 ``` 源码参考 **RequestMappingHandlerAdapter.handleInternal(464)->invokeHandlerMethod(543)-> ServletInvocableHandlerMethod.invokeAndHandle(52)->InvocableHandlerMethod.invokeForRequest(54)-->getMethodArgumentValues(62)** > 桥接模式(bridge) ``` 优点： 1.抽象和实现的分离。 2.优秀的扩展能力。 3.实现细节对客户透明。 缺点：桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。 使用场景�