ていひんのブログ

定义：定义了对相间的一对多依赖，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有观察者都会收到通知并更新。 类型：行为型； 适用场景：关联行为场景、建立一套触发机制； 优点： 观察者和被观察者之间建立一个抽象的耦合； 观察者模式支持广播通信； 缺点： 观察者之间有过多的细节依赖，提高时间消耗及程序复杂度； 使用要适当，要避免循环调用； 观察者模式UML类图： 示例：...

定义：为请求创建一个接收此次请求对象的链，对该请求对象执行一系列的操作。 类型：行为型； 使用场景：一个请求的处理需要多个对象当中的一个或几个协作处理； 优点： 请求的发送者和接收者（请求的处理）解耦； 责任链可以动态组合； 缺点： 责任链太长或者处理时间过长，影响性能； 责任链有可能过多； 示例：   本文通过博客（Blog）发布流程中的title、author、type、content...

定义：为其他对象提供一种代理，以控制对这个对象的访问，代理对象在客户端和目标对象之间起到中介的作用； 类型：结构型； 适用场景： 保护代理对象； 增强代理对象； 优点： 将代理对象与真实被调用的目标对象分离； 一定程度上降低了系统耦合度，扩展性好； 保护目标对象； 增强目标对象； 缺点： 代理模式会造成系统设计中目标类增加； 在客户端和目标对象之间增加一个代理对象，相对会造成请求处理速度...

定义：将“请求”封装成对象，以便使用不同的请求，命令模式解决了应用程序中对象的职责以及他们之间的通信方式； 类型：行为型； 适用场景： 请求调用者和请求接收者需要接耦，使得使用者和接收者不直接交互； 需要抽象出等待执行的行为； 优点： 降低耦合； 容易扩展新命令或者一组命令； 缺点： 命令的无限扩展会增加类的数量，提高系统实现复杂度； 课程命令举例： // 课程类 public cla...

定义：允许一个对象在其内部状态改变时，改变它的行为； 类型：行为型； 适用场景 一个对象存在多个状态（不同状态行为不同），且状态可相互转换； 优点 将不同的状态隔离； 把各种状态的转换逻辑，分布到state的子类中，减少相互间依赖； 增加新的状态非常简单； 缺点 状态多的业务场景导致类数目增多，系统变复杂； 视频状态转换举例 // 视频状态抽象类 public abstract cla...

定义：定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化不会影响到使用算法的用户，且可以替换掉程序中大量的“if-else”语句； 类型：行为型； 适用场景 系统有很多类，而它们的区别仅仅在于行为不同 一个系统需要动态地在算法中选择出一种 优点 符合开闭原则 可以避免大量的条件转移语句（if-else,switch） 提供算法的保密性和安全性 缺点 客户端必须要知道...

定义：将抽象部分与它的具体实现部分分离，使它们都可以独立地变化，通过组合的方式建立两个类之间的联系，而不是继承； 类型：结构型； 适用场景 抽象与具体实现之间增加更多的灵活性； 一个类存在两个或多个独立变化的维度，且这两个或多个维度都需要独立进行扩展； 不希望使用继承，因为多层继承会使系统类的数量剧增； 优点 分离抽象部分与其具体实现部分； 提高了系统的可扩展性； 符合开闭原则； 符合组合复...

定义：将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使对单个对象和组合对象保持一致的方式处理； 类型：结构型； 优点： 清楚地定义分层次的复杂对象，表示对象的全部或部分层次； 让客户端忽略了层次的差异，方便对整个层次结构进行控制； 简化客户端代码； 符合开闭原则； 缺点： 限制类型时会较为复杂； 使设计变得更抽象； 举例 // 目录组件 public abstract cla...

定义：将一个类的接口转换成客户期望的另一个接口，使原本接口不兼容的类可以一起工作； 类型：结构型； 适用场景： 已经存在的类，他的方法和需求不匹配时（方法结果相同或类似）； 不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品不同厂家造成功能类似而接口不相同情况下的解决方案； 优点： 能提高类的透明性和复用，现有的类复用但是不需要改变； 目标类和适配器类解耦，提高程序扩展性； 符合开...

定义：在不改变原有对象的基础上，将功能附加到该对象，提供了比继承更有弹性的替代方案（扩展原有对象功能）； 类型：结构型； 使用场景：  1、扩展一个类的功能，或给一个类添加附加职责；  2、动态地给一个类添加功能，这些功能可以动态地再撤销； 优点：  1、继承的有力补充，比继承灵活，不改变原有对象的情况下给对象一个扩展功能；  2、通过使用不同装饰类以及这些装饰类的排列组合可以实现不同的效果；  ...

  容器单例模式使用的是HushMap，作为缓存使用，线程不安全，但是易于管理，可在合适的场景下使用，具体实现如下： public class ContainerSingleton { private ContainerSingleton(){} private static Map<String,Object> singletonMap = new HashMap&...

  枚举类型天然的可序列化机制，能够强有力的保证不会出现多次实例化的情况，即使在复杂的序列化或者反射攻击的情况下，枚举类型的单例模式都没有问题。枚举类型的单例可能是实现单例模式中的最佳实践，《Effcetive Java》这本书也是强力推荐这种写法。 1、枚举实现单例模式 public enum EnumInstance { INSTANCE; private Object dat...

  反射可以通过修改私有构造器的访问权限，或者修改单例类的某些属性值，来获取新的实例，从而破坏单例模式。 public class Test { public static void main(String[] args) throws IOException, ClassNotFoundException, NoSuchMethodException, IllegalAccessExce...

  将单例对象序列化和反序列化操作后得到的新对象与原单例对象并不相同，因为反序列化是通过反射获取的新对象。 public class Test { public static void main(String[] args) throws IOException, ClassNotFoundException { HungrySingleton hungrySingleto...

单例模式 定义：保证一个类仅有一个实例，并提供一个全局访问点。 类型：创建型。 适用场景：想确保在任何情况下都只有一个实例（程序计数器、数据库连接池、线程池）。 优点： 在内存里只有一个实例，降低了内存开销； 可以避免对资源的多重占用； 设置全局访问点，严格访问控制； 缺点：没有接口，扩展困难。 重点： 私有构造器，禁止从外部创建对象； 线程安全； 延迟加载，使用时再创建； 序列化和反序列化...