读《设计模式与领域驱动设计》有感

写之前，再回顾小知识点，接口和抽象类的区别，设计模式更多的是做封装，复用清晰维护的思想与接口抽象类不谋而合，接口作用：抽象方法的集合，自身不能实现逻辑，只能被implement；抽象类：不能被实例化，只能作为基类超类被子类extends 继承，用于定义共通的方法，常用子类的方法模板通用特性，其他和普通类没区别，

上篇设计模式与DDDhttps://blog.csdn.net/qq_32447321/article/details/111415718,本篇作为实践增加以往项目联想

1：模式：工厂模式

1.1 : 工厂模式又细分为工厂方法模式和抽象工厂模式，本文主要介绍工厂方法模式。

模式定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法是一个类的实例化延迟到其子类。
抽象一个产品基类，定义多个不同子的产品基于（extend）产品基类；每个子的产品执行各自具体的逻辑 //抽象的工厂，实例化此基类
//具体(子)的工厂可以生产出相应的（基类）子类产品

• 场景：1.2: 在一个IOT项目实践中运营数据监管统计，Car类作共通的”整车数据“基类，子类分燃油车（油耗），电动车（电瓶数据统计）；

2：模式：策略模式

• 模式定义：定义一系列算法，将每个算法都封装起来，并且它们可以互换。策略模式是一种对象行为模式。
  用途工厂模式和策略模式结合在一起，就完成了整个返奖的过程：

工厂方法模式帮助我们直接产生一个具体的策略对象，策略模式帮助我们保证这些策略对象可以自由地切换而不需要改动其他逻辑，从而达到解耦的目的。通过这两个模式的组合，当我们系统需要增加一种返奖策略时，只需要实现RewardStrategy接口即可，无需考虑其他的改动。当我们需要改变策略时，只要修改策略的类名即可。不仅增强了系统的可扩展性，避免了大量的条件判断，而且从真正意义上达到了高内聚、低耦合的目的。
场景：app内用户充值金额大小进行返奖机制，n个等级,不同的等级对应不同的策略；游客购买车票时，购买的数量分等级，然后返现金额策略等每个返奖策略都包括返奖金额计算、更新用户奖金信息、以及结算这三个步骤。

使用工厂模式生产出不同的策略，同时使用策略模式来进行不同的策略执行。

3：模式：状态模式
每一个状态要进行的动作和操作都是不同的。因此，使用状态模式，能够帮助我们对系统状态以及状态间的流转进行统一的管理和扩展。

• 模式定义：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
  工程实践：当前的状态只负责当前状态要处理的事情，状态的流转则由第三方类负责。其实践代码如下：
  状态模式的核心是封装，将状态以及状态转换逻辑封装到类的内部来实现，也很好的体现了“开闭原则”和“单一职责原则”。
  每一个状态都是一个子类，不管是修改还是增加状态，只需要修改或者增加一个子类即可。在我们的应用场景中，状态数量以及状态转换远比上述例子复杂，
  通过“状态模式”避免了大量的if-else代码，让我们的逻辑变得更加清晰。
  同时由于状态模式的良好的封装性以及遵循的设计原则，让我们在复杂的业务场景中，能够游刃有余地管理各个状态。
• 场景：1：新能源车主申请补贴提交材料（上传身份证，人脸识别，车辆材料上传），对于提交业务流程映射系统状态适用状态模式。2：用户小程序或app在 支付充值退款等状态，每个状态都是独立，只负责当前状态要处理的事情

4：模式：责任链模式

• 模式定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
  责任链模式最重要的优点就是解耦，将客户端与处理者分开，客户端不需要了解是哪个处理者对事件进行处理，处理者也不需要知道处理的整个流程。

在我们的系统中，后台的过滤规则会经常变动，规则和规则之间可能也会存在传递关系，通过责任链模式，我们将规则与规则分开，
将规则与规则之间的传递关系通过Spring注入到List中，形成一个链的关系。当增加一个规则时，只需要实现BasicRule接口，然后将新增的规则按照顺序加入Spring中即可
。当删除时，只需删除相关规则即可，不需要考虑代码的其他逻辑。从而显著地提高了代码的灵活性，提高了代码的开发效率，同时也保证了系统的稳定性。

实现的内容
 1. 指向下一个处理者
 2. 处理者能够处理的级别
 3. 抽象方法，子类实现

• 场景：有序的, 过滤规则的解耦，责任链模式最重要的优点就是解耦，将客户端与处理者分开，客户端不需要了解是哪个处理者对事件进行处理，处理者也不需要知道处理的整个流程。