设计模式-学习笔记

1.UML类图：
● 继承。空心三角形箭头，实线。
● 实线。空心三角形箭头，虚线。
● 组合关系同样表示整体由部分构成的语义，但组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也不存在了。实心菱形、实线表示。
● 聚合关系用于表示实体对象之间的关系，表示整体由部分构成的语义。整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。空心菱形、实线表示。
● 关联。 实线表示。它描述不同类的对象之间的结构关系，它是一种静态关系， 通常与运行状态无关，一般由常识等因素决定的。它一般用来定义对象之间静态的、天然的结构， 所以，关联关系是一种“强关联”的关系。
● 依赖 。 普通箭头、虚线表示。依赖关系是用一套带箭头的虚线表示的，如A依赖于B，他描述一个对象在运行期间会用到另一个对象的关系。与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化，依赖关系也可能发生变化。显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生。
2. 六大原则
● 开闭原则：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
● 里氏替换原则：所有引用基类对象的地方能够透明地使用其子类的对象
● 依赖倒置原则：抽象不应该依赖于具体类，具体类应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
● 单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
● 迪米特法则（最少知道原则）：一个软件实体应当尽可能少地与其他实体发生相互作用
● 接口分离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
设计模式可分为
创建型(Creational)
创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将模块中对象的创建和对象的使用分离。为了使结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。

1. 简单工厂模式（Simple Factory Pattern）
2. 工厂方法模式（Factory Method Pattern）
3. 抽象工厂模式（Abstract Factory Pattern）
4. 单例模式（Singleton Pattern）
5. 生成器模式（Builder Pattern）
6. 原型模式（Prototype Pattern）
   结构型(Structural)
   结构型模式(Structural Pattern)描述如何将类或者对 象结合在一起形成更大的结构，就像搭积木，可以通过 简单积木的组合形成复杂的、功能更为强大的结构。结构型模式可以分为类结构型模式和对象结构型模式：
   ● 类结构型模式关心类的组合，由多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。
   ● 对象结构型模式关心类与对象的组合，通过关联关系使得在一 个类中定义另一个类的实例对象，然后通过该对象调用其方法。 根据“合成复用原则”，在系统中尽量使用关联关系来替代继 承关系，因此大部分结构型模式都是对象结构型模式。
7. 外观模式
8. 适配器模式
9. 桥接模式
10. 代理模式
11. 装饰者模式
12. 享元模式
    行为型(Behavioral)
    行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。行为型模式不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。
13. 职责链模式
14. 命令模式
15. 解释器模式
16. 迭代器模式
17. 中介者模式
18. 备忘录模式
19. 观察者模式
20. 状态模式
21. 策略模式
22. 模板方法模式
23. 访问者模式
    具体常用合计模式介绍
    1、简单工厂模式又叫 静态方法模式。
    因为工厂类中定义了一个静态方法用于创建对象。简单工厂让使用者不用知道具体的参数就可以创建出所需的 ”产品“ 类，即使用者可以直接消费产品而不需要知道产品的具体生产细节、简单工厂模式(Simple Factory Pattern)：专门定义一个类（工厂类）来负责创建其他类的实例。可以根据创建方法的参数来返回不同类的实例，被创建的实例通常都具有共同的父类。
    简单工厂模式像一个代工厂，一个工厂可以生产多种产品。举个例子，一个饮料加工厂同时帮百事可乐和可口可乐生产，加工厂根据输入参数Type来生产不同的产品。
    试例

以饮料加工厂为例
1. 创建饮料接口(或者抽象类)
public interface Drink {
    void production();
}
-------------------------------------------代码
2. 具体饮料类的实现(可乐、雪碧)
public class ColaDrinkProduction implements Drink{
    @Override
    public void production() {
        System.out.println("生产可乐饮料");
    }
-------------------------------------------代码
public class SpriteDrinkProduction implements Drink{
    @Override
    public void production() {
        System.out.println("生产雪碧饮料");
    }
}
-------------------------------------------代码
3. 饮料生产工厂类
public class DrinkProductionFactory {
    public static Drink productionDrink(String type){
        switch (type){
            case "cloa":
                return new ColaDrinkProduction();
            default:
                return new SpriteDrinkProduction();
        }
    }
}
-------------------------------------------代码
4. 工厂调用
需要什么对象传入对应的参数即可
Drink cloa = DrinkProductionFactory.productionDrink("cloa");
 cloa.production();
-------------------------------------------代码
特点
它是一个具体的类，非接口 抽象类。有一个重要的调用方法(productionDrink)，通常是静态的，利用if或者 switch创建产品并返回
缺点
扩展性差 我想增加一种饮料，除了新增一个饮料产品类，还需要修改工厂类方法(增加‘Case'的分支条件) 这样来说 不但对扩展开放了，对修改也开放了 违背了开放-封闭原则

参考：https://juejin.cn/post/6844903795017646094