设计模式

设计模式的类型

• 创建型模式
  • 隐藏了创建对象的过程，通过逻辑方法进行创建对象，而不是通过new关键字创建对象。
    • 工厂方法模式
      • 定义接口或一个抽象的工厂类，让它实现类（工厂）来决定创建哪一个实例对象。
      • 根据每个工厂不同的方法，来产生不同的所需要的对象。
      • 工厂方法模式生产的都是相同系列的对象，比如Java课程，Python课程。
    • 抽象工厂模式
      • 类似公司下的产品，生产汽车，将汽车分为各个零部进行生产，车架，车门，地盘；
      • 抽象工厂模式提供了创建一系列相关或互相依赖的接口；
    • 建造者模式
      • 将复杂的对象的创建和属性赋值所分离。
      • 监造的过程和细节我们不需要知道，只需要通过构建者区进行操作。
    • 原型模式
      • 用于创建重复对象，能够保证对象的性能。
      • 原型设计模式是创建对象的最佳方式。
    • 单例模式
      • 在程序种想要保存一个实例对象，就是用单例设计模式
      • 减少内存开销
        • 懒汉式
          • 在需要使用对象的时候，才会创建
        • 双重检查
          • 通过两个if判断加上同步锁进行实现
        • 静态内部类
          • 在单例类种，通过私有的静态内部内，创建单例对象
        • 饿汉式
          • 在调用时，就会创建单例对象，通过静态代码块或静态变量初始化
        • 枚举
          • 枚举的方式实现单例模式，是最佳的实现方式
          • 它可以有效防止单例模式的破坏
            • 序列化和反序列化的方式破坏单例模式
              • 通过流将单例对象，序列化到文件中，然后再反序列化读取出来
              • 最终通过反序列化的方式创建一个对象
              • 发现两个对象的内存地址完全不一致，从而破坏了单例设计模式结构
              • 在单例类中，写一个名称必须为readResolve
                • 因为在反序列化创建对象时，是通过反射创建的
                • 反射会调用我们自己的readResolve
                • 如果充血的，就代表返回自己的单例对象
                • 如果没有重写，回通过反射的方式，创建一个新对象，从而破坏单例设计模式

              private Object readResolve() {return doubleCheckSingleton;}     
              

          • 通过反射的方式破坏单例模式
            • 通过字节码对象，创造构造器对象，
            • 通过构造器对象，创建初始化单例对象
              • 由于单例对象的构造方法是私有化的
              • 调用构造器中的方法，赋予权限，创建单例对象
• 结构型模式
  • 主要关注类和对象的组合关系。
  • 继承的概念主要用来组合接口和定义组合对象，获得新的功能方式。
    • 外观模式
      • 迪米特原则的体现
      • 提供了一个统一的接口，用来访问子系统中的一群接口
      • 定义了一个高层接口，让子系统更加容易
    • 适配器模式
      • 适配器模式（Adapter Pattern）是作为两个不兼容接口之间的桥梁，将一个类的接口转换成客户希望的另外一个接口
      • 适配器模式是的原本由于接口不兼容而不能一起工作的那些类可以一起工作
      • 这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能
      • 将不同的接口的对象，转换成相同的一同工作
    • 桥接模式
      • 桥接（Bridge）是用于抽象化与是鲜花的解耦，使得二者可以独立变化。
      • 这种类型的设计模式属于结构型模式，它通过抽象化与是鲜花之间的桥接结构，来实现二者的解耦。
      • 这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现。这两种类型的类可以被结构化而不互相影响。
      • 组合模式
        • 组合模式（Composite Pattern），又叫部分整体模式，适用于把一组相似的对象当作单一的对象。
        • 组合模式一句树形结构来组合对象，用来表示部分以及整体层次；
        • 这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。
        • 允许将对象组合成 树状结构 以表示 “部分-整体”的层次结构
        • 我们通过下面的实例来演示组合模式的用法，实例演示了一个组织中的员工层次结构。

          优点：
          统一接口： 组合模式通过使用统一的接口，使得客户端可以一致地处理单个对象和组合对象，简化了客户端的代码。
          灵活性： 可以通过组合模式构建复杂的 树形结构，使得系统具有更高的灵活性和可扩展性。可以随时添加新的叶子节点或容器节点，而不需要修改已有的代码。
          可重用性： 叶子节点和容器节点的组合关系使得这些节点可以被重复使用，促进了代码的重用。
          简化客户端代码： 客户端无需关心处理单个对象还是组合对象，可以简化客户端代码，提高代码的可维护性。缺点：
          可能过于一般化： 在某些情况下，组合模式可能过于一般化，不容易满足特定的需求。例如，可能会导致在叶子节点和容器节点上都定义了一些对于某个节点类型不适用的操作。
          可能导致性能问题： 在处理大型树形结构时，组合模式可能导致性能问题，因为递归地处理整个结构可能会引起性能开销。
          难以限制组件类型： 组合模式难以限制组件类型，因为客户端对于叶子节点和容器节点的操作是一致的。这可能导致在不同类型的组件上执行不适用的操作。   
          

    • 代理模式
      • 为对象提供一种代理，以控制这个对象的访问操作
      • 代理对象和目标对象之间起到中介的作用
      • 保护目标对象和增强目标对象
      • 代理模式能将代理与真实被调用的目标对象分离
      • 一定程度上降低了系统的耦合，扩展性好
    • 装饰模式
      • 在原有对象不做改变的基础上，将对象的功能加上
      • 提供了比继承更有弹性的替代方案（扩展原有对象功能）
      • 扩展一个类的功能或给一个类添加追加职责
      • 动态的给一个对象添加功能，这个功能可以再动态撤销
      • 继承有利补充，比继承灵活，不改变原有对象的情况下给一个对象扩展功能
      • 通过使用不同的装饰类以及这些装饰类的排列组合，可以实现不同的效果；
    • 享元模式
      • 提供了减少对象数量从而改善了应用所需的对象结构的方式
      • 运用了共享技术有效地支持大量细粒度的对象
      • 总结：减少创建的数量，从而减少内存的占用，提升性能
• 行为型模式
  • 主要关注对象之间的通信。
    • 模板方法模式
      • 定义了一个算法的架构，并允许子类为一个或多个步骤的实现
      • 模板方法在子类不改变算法结构的情况下，重新定义算法的某些步骤
      • 实现一个算法的不变的部分，并将可变的空间留给子类完成
      • 子类中公共的行为抽取出来并封装到一个公共父类中，避免代码重复
    • 迭代器模式
      • 提供方法，顺序访问集合对象中的各个元素，而又不爆露对象的内部展示
      • 为遍历不同的集合结构提供统一的接口，分离了集合对象的遍历能力
    • 策略模式
      • 定义了算法，分别封装起来，他们之间可以互相替换，让算法的变化不会影响到使用算法的用户
      • 如果有大量的if…else，可以用过策略模式进行替换
      • 避免使用多重条件转语句，if…else if…else
      • 提高算法的保密性和安全性
    • 解释器模式
      • 通过给定的语言，定义它的语法和行为，并定义解释器，这个解释器使用来解释语言中的句子
      • 为了解释一种语言，而为语言创建的解释器；
      • 某个类型问题触发频次足够该，比如处理日志和不同日志的格式
    • 观察者模式
      • 当对象间存在一对多关系时候，则使用观察者模式（Observer Pattern）
      • 比如，当一个对象被修改时，则会自动通知依赖它的对象
      • 让多个观察者对象同时监听某一个主题对象，当主题发生变化时候，它的所有的依赖着（观察者）都会收到通知并更新
    • 备忘录模式
      • 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态
      • 所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以以后将对象回复到原先保存的状态。
      • 很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误操作，能否恢复到他原先的状态，使他有“后悔药”可吃。
    • 命令模式
      • 数据驱动的设计模式
      • 将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化，解决了应用程序库中对象的职责以及它们之间的通信方式
      • 在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录，撤销或重做，事务等，这种无法抵御变化的紧耦合的设计就不太合适。
      • 请求调用者和行为实现这需要解耦，是的调用者和行为者不直接交互
    • 中介者模式
      • 中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性，这种模式提供了一个中介类。该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。
      • 用一个中介对象来封装一系列对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合，而且可以独立改变它们之间地交互。
      • 对象与对象之间存在大量地关联关系，这样势必会导致系统地结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之关联地对象，同时做出相应地处理。
      • 对象
    • 责任链模式
      • 为请求创建了一个接收者对象的链。对请求的发送者和接收者进行解耦。
      • 在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者。
      • 避免请求的发送者和接收者耦合在一下，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条聊条传递请求，直到所有对象都处理完成。
      • 责任链上的处理者负责处理请求，客户只需要将请求发送到责任链上即可，无需关心请求的处理细节和请求的传递，所以责任链将请求的发送者和请求的矗立着解耦。
    • 访问者模式
      • 使用了一个访问者类，它改变了元素类的执行算法
      • 通过这种方式，元素的执行算法可以随着访问者改变而改变，这类型的设计模式输运行为型模式
      • 根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作
      • 主要将数据结构与数据操作分离。稳定的数据结构和易变的操作耦合问题。
    • 状态模式
      • 在状态模式（State Pattern）中，类的行为是基于它的状态改变的。
      • 允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
      • 对象的行为依赖于它的状态（属性），并且可以根据它的状态而改变它的行为。