Question

我不得不清理在线大学申请的代码。这没有什么特别的错，但它很复杂。不同的学位课程有不同的先决条件，费用，所需的文件和问题。最重要的是，来自军方的学生会收取不同的费用，以前的学生不收取任何费用并跳过步骤。

显然，所有这些逻辑都会变得非常复杂 - 并导致错误。我想知道是否有一种设计模式或编码方法可以帮助组织逻辑。我正在使用PHP，而不是重要。

strategy pattern似乎最具潜力，但在我看来，我需要在策略之上制定策略。

我认为“商业逻辑”这个领域可能至少部分涵盖了这一点，但搜索并没有显示出任何优雅的编码方法可供使用。

Answer 1

我认为组合模式会有所帮助。 Fowler's Domain Model pattern旨在驯服复杂的域逻辑。使用分层架构模式是另一种选择，如POSA1中所述。策略模式似乎也是定义一系列相关算法的好主意。

Answer 2

作为一个起点，您遇到过unit testing吗？一个用于PHP单元测试的快速谷歌提出了http://www.phpunit.de/。

作为起点，您应该查看是否可以对现有代码进行单元测试。通过这种方式，您可以确信它能够实现其意图并且应该能够在未来进行更改而不必担心破坏现有逻辑。此外，一旦您对现有代码进行了单元测试，您就可以进行更改，以相同的置信度改进逻辑。

Answer 3

如你所说，状态模式听起来很合适 - 但是如果有一些复杂的逻辑，你会想把它放在domain model中，而不是transaction script你现在可能正在使用它。

福勒的书Patterns of Enterprise Application Architecture对你的应用程序的整个思考领域有很好的解释（他建议你从那开始并从那里开始工作）。

正如其他人所说，单元测试总是有帮助的！

Answer 4

我不相信这种问题是通过一种或多种模式来解决的。在某种程度上是“只是设计” - 你构建一个设计并发现关系和弯曲点，其中OO技术（例如）帮助并在那时模式发挥作用。

多年来，我观察到很多尝试通过“不写代码”来解决这些问题。这就是我们找到一些方法将业务逻辑外部化为比代码更具有可塑性的东西。所以可能只是你将费用规则外部化了：

  Thinking 101  Standard $100   Alumni $50   Ex-Military $0
  Hard Sums     Standard $500   Alumni $100  Ex-Military $0

现在，这些规则的更改是配置更改而不是代码更改。这种数据驱动的appraoch可能比代码更好。

然后你想要将逻辑外化，因此规则引擎会出现。

外部处理逻辑，因此我们得到BPEL。

我看到所有这些方法都取得了成功，但是......实际上你已经将逻辑外化到了某个地方，所以仍然存在两个问题：

这个东西仍然是软件，它实际上是代码伪装。

Answer 5

应用一些设计模式并不能解决所有问题，但有些可能有助于更好地组织代码。如果您想减少错误，那么请实施某种自动化测试，查看测试驱动开发和持续集成方法。