想象一下这个场景；您的任务是编写一些在系统中创建销售订单的代码。您可以选择使用SAP提供的标准BAPI。漂亮、干净的代码正在生产中运行。

然后，几周后，一个应用程序顾问通知您，只有一个使用该解决方案的客户的业务需求发生了变化；他们需要首先检查订购的材料是否有适合一次交货的库存量-如果不可能，请不要创建订单。

因此您修改了原始解决方案并增加了一些复杂性。不多，只有一个'如果'分支和一些处理逻辑，只为一个客户。没问题。

下周，您的电子邮件中会出现一个新的要求；如果交货工厂距离发货方超过500公里，并且订单属于某种类型，则不要创建订单。更多的检查代码进入你原来的，优雅的解决方案。

两周后，另一个检查要求实现；一个月后，又一个。到现在为止，你的代码开始有点"味道"–这不是你的错，你怎么知道这些小检查和随后的实现会给你曾经干净的代码增加额外的复杂性，而你的代码最初唯一的职责就是根据提供的数据创建销售订单。

一年之后，这条线，以及代码已经从有些不雅变成了几乎不可维护；检查已经形成了一个意大利面代码的泥潭，很难通读和理解所有的业务需求是什么。任何附加的逻辑都可能会引入意外的副作用，从而导致回归测试失败，因为代码中有太多的路径，以至于测试变成了一场噩梦；顾问已经离开了，那云，开发人员已经离开了，理解代码的复杂性的确是一项艰巨的任务。

不仅如此，但每次代码被修改时，意味着源代码被打开、编辑和传输，增加了额外的风险，一旦被测试的代码被意外地更改，在代码被发布到生产环境之后，通过后续的验尸来发现到底出了什么问题？

根本原因

这一切混乱的根本原因是什么？一句话，物联网公司，不可预测性。在设计时收集所有的需求是不可能的，如果按照敏捷方法来工作的话，这甚至是不可能的。随着时间的推移，需求不断发展，新的客户和业务条件不断出现，因此，即使在设计过程的开始阶段，需求分析已经完全全面，购物返利，新的需求也会不断涌现。

无论如何，为什么要让原来的代码来做所有的检查呢？毕竟，它的目的是做一件事：创建销售订单。让它做任何其他事情都违反了实体设计的第一个原则，即单一责任原则，该原则规定：

"一个类改变的原因不应超过一个。"

如果有一种方法可以将所有这些代码签出分离成更小的、独立的代码单元，这些代码单元可以在使用中交换，也可以在使用中交换，不需要打开原始代码并重新编译它？如果这些检查可以重复使用，消除重复的代码呢？如果一些客户需要一些其他人不需要的检查怎么办

如果代码从一开始就可以防止代码腐烂的破坏怎么办？

输入规则模式

我要感谢Steve Smith，他是这个设计模式的创始人。

规则模式是专门为解决这个问题而设计的：

代码变得过于复杂；额外的检查逻辑不断地添加到原始功能中具有一个原始职责的代码被赋予与执行额外任务相关的额外关注点执行这些额外任务的逻辑与原始代码交织在一起

我对规则模式的实现比原始模式走得更远一些，所以我将把它分解为几个部分，然后在最后看看它们是如何协同工作的。所有这一切的核心是一个单一的组成部分，在概念上被认为是一个规则。

规则是对一个系统的特定条件或状态的基本的、原子的检查。简而言之，它是一种检查是否满足某个条件的方法。

通常需要设置规则，即提供有关系统状态的信息并执行，以评估规则的结果。

基本架构如下所示。

让我们看看上图的显著特征。我们有：

合同定义的规则。包含两个方法：PREPARE（）和EXECUTE（）。

PREPARE（）：准备规则。传入EXECUTE方法所需的任何数据。

下面是一个简单PREPARE（）语句的示例：

强制转换是因为我传入了一个已知类型的对象，该对象需要在此示例中显式声明。重要的一点是，我只是在这条语句中设置了一个销售订单的单据号和销售订单的料号，没有别的了

EXECUTE（）：执行规则。请注意该方法返回的参数：

EX\u STATE返回三个级别中的一个：PASS、FAIL或WARN，指的是评估后规则的状态。

EX\u ABORT表示其他规则发生了什么，将其设置为"TRUE"就足以阻止任何进一步的规则检查，因为发生了什么；这是一种系统关了所有的赌注！'indicator.