读了着篇文章之后发现真的是，你的思想，你的思维是真的比比你拥有什么技术要强的。

注 

开闭原则

开闭原则（Open-Closed Principle）是面向对象设计中的基本原则之一，它的定义是：一个软件实体应该对扩展开放，对修改关闭。也就是说，在软件的生命周期内，当需要对软件进行修改时，应该通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

开闭原则的目的是提高软件的可复用性和可维护性。在软件开发过程中，随着业务需求的变化，软件需求可能会发生变化，而开闭原则可以帮助我们避免对现有代码的修改，从而减少引入新错误和重构整个功能的风险

迪米特法则

迪米特法则（Law of Demeter，LoD）是一种面向对象设计原则，也被称为最少知识原则（Least Knowledge Principle，LKP）。它指出一个软件实体应当尽可能少地与其他实体发生相互作用。如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。

迪米特法则的核心思想是降低组件之间的耦合度，提高代码的松耦合性，从而使得代码更易于维护、扩展和重构。在迪米特法则的指导下，一个类应该尽可能少地与其他类发生相互作用，尽量避免直接相互依赖，而是通过接口、抽象类等机制来进行通信，使得类与类之间的联系更加松散，易于维护和扩展。

迪米特法则的命名来源于古希腊神话中的人物狄米特（Demeter），她是希腊神话中的农业女神，也是宙斯的姐姐。在这个神话中，狄米特规定了农业的生产规律，类似于迪米特法则规定了软件实体之间的通信规律。

围绕高内聚和低耦合两个方面，然后结合设计模式

围绕高内聚和低耦合两个方面，然后结合设计模式

围绕高内聚和低耦合两个方面，然后结合设计模式

奖励发放策略

第一天，老师问小明：“你知道活动营销吗？”
“这我知道，活动营销是指企业通过参与社会关注度高的已有活动，或整合有效的资
源自主策划大型活动，从而迅速提高企业及其品牌的知名度、美誉度和影响力，常见
的比如有抽奖、红包等。”
老师点点头：“是的。我们假设现在就要做一个营销，需要用户参与一个活动，然后完
成一系列的任务，最后可以得到一些奖励作为回报。活动的奖励包含美团外卖、酒旅
和美食等多种品类券，现在需要你帮忙设计一套奖励发放方案。”
因为之前有过类似的开发经验，拿到需求的小明二话不说开始了编写起了代码：

 小明很快写好了 Demo，然后发给老师看。
“假如我们即将接入新的打车券，这是否意味着你必须要修改这部分代码？”老师
问道。

一眼就看出了端详。这不满足我们设计原则中的开闭原则，和迪米特原则。

那我们该如何进行优化呢？

这个案例就可以用适配器和策略模式来调优

策略模式 | 菜鸟教程   适配器模式 | 菜鸟教程

先通过这个策略模式优化了变成如下代码

 然后，小明创建策略模式的环境类，并供奖励服务调用：

小明的代码经过优化后，虽然结构和设计上比之前要复杂不少，但考虑到健壮性和拓展性，还是非常值得的。

策略类是有状态的模型吗？如果不是是否可以考虑做成单例的？

环境类的获取策略方法职责很明确，但是依然没有做到完全对修改封闭

解决 ：可以将策略类单例化以减少开销，并实现自注册的功能彻底解决分支判断

小明列出单例模式的要点：
单例模式  设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被
创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该
类的对象。

 最终，小明在策略环境类中使用一个注册表来记录各个策略类的注册信息，并提供接
口供策略类调用进行注册。同时使用饿汉式单例模式去优化策略类的设计：

 

 

最终，小明设计完成的结构类图如下：

如果使用了 Spring 框架，还可以利用 Spring 的 Bean 机制来代替上述的部分设计，
直接使用 @Component 和 @PostConstruct 注解即可完成单例的创建和注册，代
码会更加简洁。

一些自己的思考

在设计你的业务逻辑的时候，或者写你的逻辑的代码，一定一定要思考设计模式-创造型模式，结构型模式，和行为型模式，还有下面的

J2EE 模式 这些设计模式特别关注表示层

我们该用什么。怎么调优

任务模型的设计

现在，我想让你去完成任务模型的设计。你需要重点关注状态的流转变更，以及状态变更后的消息通知。而上一个奖励发放策略貌似是状态的一个确定。

小明呢接下了难题，他首先定义了一套任务状态的枚举和行为的枚举

然后，小明对开始编写状态变更功能

很明显上述代码 依然存在有上一个例子的问题。

问题是什么

第一，方法中使用条件判断来控制语句，但是当条件复杂或者状态太多时，条件判
断语句会过于臃肿，可读性差，且不具备扩展性，维护难度也大。且增加新的状态时
要添加新的 if-else 语句，这违背了开闭原则，不利于程序的扩展

第二，任务类不够高内聚，它在通知实现中感知了其他
领域或模块的模型，如活动和任务管理器，这样代码的耦合度太高，不利于扩展

优化

首先是状态流转的控制可以使用状态模式，其次，任务完成时的通知可以用到观察者模式

观察者模式 | 菜鸟教程 状态模式 | 菜鸟教程

根据状态模式的定义，小明将 TaskState 枚举类扩展成多个状态类，并具备完成状
态的流转的能力；然后优化了任务类的实现：

 小明欣喜地看到，经过状态模式处理后的任务类的耦合度得到降低，符合开闭原则。
状态模式的优点在于符合单一职责原则，状态类职责明确，有利于程序的扩展。这样设计的代价是状态类的数目增加了，因此状态流转逻辑越复杂、需要处理的动作
越多，越有利于状态模式的应用。

小明首先设计好抽象目标和抽象观察者，然后将活动和任务管理器的接收通知功能定
制成具体观察者：

 最后，小明将任务进行状态类优化成使用通用的通知方法，并在任务初始态执行状态
流转时定义任务进行态所需的观察者

 

最终，小明设计完成的结构类图如下

 通过观察者模式，小明让任务状态和通知方实现松耦合（实际上观察者模式还没能做到完全的解耦，如果要做进一步的解耦可以考虑学习并使用发布 - 订阅模式）

活动的迭代重构

活动模型的特点在于其组成部分较多，小明原先的活动模型的构建方式是这样的

 

上述代码得问题主要表现在

活动的构造组件较多，导致可以组合的构造函数太多，尤其是在模型增加字段时还需
要去修改构造函数

部分组件的构造存在一定的顺序关系，但是当前的实现没有体现顺序，导致构造逻辑
比较混乱，并且存在部分重复的代码

这种情况呢？我们使用创建者模式。

在实际的应用中，如果字段类型多，
同时各个字段只需要简单的赋值，可以直接引用 Lombok 的 @Builder 注解来实现
轻量的建造者。

重构完活动构建的设计后，小明开始对参加活动方法增加风控。最简单的方式肯定是

直接修改目标方法。但是是有的活动需要风控有的不需要。这时候我们就用了装饰者模式。来进行风控。