6大设计原则与23种设计模式

• 6大设计原则
  • 单一职责（Single Responsibility Principle）
    • 就一个类而言，应该仅有一个引起它变化的原因
  • 开闭原则（Open Close Principle）
    • 软件中的对象（类、模块、方法等）应该对于扩展是开放的，但是对于修改是关闭的
  • 里氏替换原则（Liskov Substitution Principle ）
    • 所有引用基类的地方必须能透明的使用其子类对象
  • 依赖倒置原则（Dependence Inversion Principle）
    • 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
  • 接口隔离原则（InterfaceSegregation Principle）
    • 类间的依赖关系应建立在最小接口上
  • 迪米特原则（Law of Demeter）也称最少知识原则（Least Knowledge Principle）
    • 一个对象应该对其它对象有最少的了解
• 23种设计模式
  • 创建型模式（5种）
    • 工厂方法模式
      • 定义：定义一个用于创建对象的接口，让子类决定实例化哪个类
      • 使用场景
        • 需要生成复杂对象的地方
      • 优缺点
        • 优点：将对象的初始化集中处理，方便管理
        • 缺点：在一定程度上会导致类结构的复杂化
    • 抽象工厂模式
      • 定义：为创建一组相关或相互依赖的对象提供一个接口，而不需要指定它们的具体实现类
      • 使用场景
        • 一个对象族具有相同的约束时
      • 优缺点
        • 优点:分离接口与实现，解耦
        • 缺点：会增加不少类文件，不太方便扩展新的产品类
    • 单例模式
      • 定义：确保某一个类只有一个实例，而且自行实例化并向整个应用程序提供这个实例
      • 使用场景
        • 需确保一个类有且只有一个对象的场景
        • 需避免产生多个对象消耗过多资源的场景
        • 某种类型的对象只应该有且只有一个对象的场景
      • 实现
        • 饿汉式
        • 懒汉式
        • Double Check Lock实现
        • 静态内部类实现单例
        • 枚举实现单例
        • 使用容器实现单例
      • 优缺点
        • 优点：减少内存开支、性能开销，避免对资源的多重占用，还可以优化共享资源访问
        • 缺点：扩展不方便，容易引发内存泄露
    • 建造者模式
      • 定义：将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示
      • 使用场景
        • 初始化复杂对象，如参数多，且很多参数都具有默认值，像常用的一些网络请求框架
      • 实现
        • 使用一个Builder类来进行对象的组装，通常为链式调用
      • 优缺点
        • 优点：良好的封装性，建造者独立，扩展性好
        • 缺点：会产生多余的Builder对象，消耗内存
    • 原型模式
      • 定义：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象
      • 使用场景
        • 类初始化需要消耗非常多的资源，这个资源包括数据、硬件资源
        • 通过new产生一个对象需要非常繁琐的数据准备或使用权限
        • 一个对象需供给其它对象访问，而且各个调用者需要修改其值时
      • 实现
        • 具体的原型类实现Cloneable接口，并重写clone()方法
      • 优缺点
        • 优点：在内存中二制流的拷贝，要比new一个对象性能好很多
        • 缺点：直接在内存中拷贝，构造方法不会执行，可能会引发一些问题
  • 结构型模式（7种）
    • 适配器模式
      • 定义：把一个类的接口变成客户期待的另一种接口，从而使原本因接口不匹配的两个类可以在一起工作
      • 使用场景
        • 接口不兼容
      • 优缺点
        • 优点：复用性好、扩展性好
        • 缺点：过多使用会让系统非常凌乱
    • 装饰器模式
      • 定义：动态的给对象增加一些额外的职责。
      • 使用场景：需要透明且动态的扩展类的功能时
    • 代理模式
      • 定义：为其它对象提供一种代理以控制对这个对象的访问
      • 使用场景
        • 当无法或不想直接访问某个对象时
    • 外观模式
      • 定义：要求一个系统的外部与其内部的通信必须通过统一的对象进行
      • 使用场景
        • 为一个复杂子系统提供一个简单接口
        • 当需要构建一个层次结构的子系统时
      • 优缺点
        • 优点：对客户程序隐藏子系统细节，方便使用
        • 缺点：当业务发生变化时，可能需要直接修改外观类，不符合开闭原则
    • 桥接模式
      • 定义：将抽象部分与实现部分分离，使它们可以独立的进行变化
      • 使用场景
        • 一个系统需要在抽象化角色与具体化角色之间增加更多的灵活性
    • 组合模式
      • 定义：将对象组合成树形结构以表示部分-整体的层次结构，使得用户对单个对象和组合对象的使用具有一致性
      • 使用场景
        • 表示对象的部分-整体结构时
        • 从一个整体中能独立出部分模块或功能的场景
    • 享元模式
      • 定义：使用共享对象可有效的支持大量地细粒度对象
      • 使用场景
        • 系统中存在大量相似对象
        • 需要缓冲池的场景
      • 优缺点
        • 优点：大幅度降低内存中对象的数量
        • 缺点：增加系统复杂度
  • 行为型模式（11种）
    • 策略模式
      • 定义：定义了算法族，分别封装起来，让它们之间可以相互替换，让算法的变化独立于使用算法的客户
      • 使用场景
        • 针对同一问题的多种处理方式
        • 出现同一抽象类有多个子类，又需要根据条件判断来选择具体子类时
      • 优缺点：
        • 优点：结构清晰、降低耦合
        • 缺点：随着策略的增加，子类也会变得繁多
    • 模板方法模式
      • 定义：定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤。
      • 使用场景
        • 多个子类有公有的方法，并且逻辑基本相同
      • 优缺点
        • 优点：便于维护，封装不变部分，扩展可变部分
        • 缺点：增加代码阅读难度
    • 观察者模式
      • 定义：定义对象间一种一对多的依赖关系，使得每当一个对象状态发生改变，则所有依赖于它的对象都会得到通知并自动更新
      • 使用场景
        • 关联行为场景
        • 跨系统消息交换场景
      • 优缺点
        • 优点：观察者与被观察者抽象耦合，扩展性好
        • 缺点：通知默认是顺序执行，一个观察者卡顿会影响整体效率
    • 迭代器式
      • 定义：提供一种方法顺序访问容器对象中的各个元素，而又不需要暴露该对象的内部展示
      • 使用场景
        • 遍历一个容器对象时
      • 优缺点：
        • 优点：支持以不同方式去遍历容器对象
        • 缺点：增加类文件
    • 责任链模式
      • 定义：使多个对象都有机会处理请求，从而避免了发送者与接收者之间的耦合关系，将这些对象边成一条链，并沿着这条链发送该请求，直到有对象处理它为止。
      • 使用场景
        • 多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定
      • 优缺点
        • 优点：对请求者和接收者关系解耦，提高代码的灵活性
        • 缺点：对链中处理者的遍历会影响一定的效率
    • 命令模式
      • 定义：将一个请求封装成一个对象，从而让用户使用不同的请求使客户端参数化；对请求进行排队或记录请求日志，以支持可撤销的操作。
      • 使用场景
        • 需要支持撤销操作
        • 需要支持事务操作
      • 优缺点：
        • 优点：灵活解耦
        • 缺点：类膨胀
    • 备忘录模式
      • 定义：在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样，以后就可以将该对象恢复到原先保存的状态
      • 使用场景
        • 需要保存一个对象在某一时刻的状态或部分状态
      • 优缺点
        • 优点：给用户提供一种可恢复状态的机制，实现信息封装
        • 缺点：消耗资源
    • 状态模式
      • 定义：当一个对象的内存状态改变时允许改变其行为，这个对象看起来是改变了其类
      • 使用场景
        • 一个对象的行为取决于它的状态，并且它在运行时必须根据状态改变其行为
        • 代码中包含大量与状态有关的条件语句时
      • 优缺点
        • 优点：避免代码膨胀的同时保证了扩展性及可维护性
        • 缺点：会增加相应的类文件及对象
    • 访问者模式
      • 定义：封装一些作用于某种数据结构中各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新操作。
      • 使用场景
        • 对象结构比较稳定，但经常要在此对象结构上定义新的操作
      • 优缺点
        • 优点：各角色职责分离，符合单一职责原现，扩展性好
        • 缺点：违反迪米特原则、依赖倒置原则，具体元素更改时修改成本大
    • 中介者模式
      • 定义：包装了一系列对象相互作用的方式，使得这些对象不用相互明显作用。从而可以使它们可以松散耦合。当某些对象之间的相互作用改变时，不会立即影响其它对象间的相互作用。保证这些作用可以彼此独立的变化。将多对多的相互作用转换为一对多的相互作用，将对象的行为和协作抽象化，把对象在小尺度的行为上与其它对象的相互作用分开处理。
      • 使用场景
        • 当对象之间的相互操作很多且每个对象的行为都依赖彼此时，为防止修改一个对象的行为时同步修改其它对象的行为场景
      • 优缺点
        • 优点：适当使用可以使这种依赖关系解耦
        • 缺点：使用不当会使逻辑复杂化
    • 解释器模式
      • 定义：给定一个语言，定义它文法的一种表示，并定义一个解释器使用该表示来解释语言中的句子
      • 使用场景
        • 如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象语法树时
        • 在某些特定领域出现不断重复的问题时，可以将该领域下的问题转化为一种语法规则下的语句，然后构建解释器来解释该语句
      • 优缺点
        • 优点：扩展性好
        • 缺点：创建大量的类，导致后期维护困难