显然,所有这些逻辑都可能变得非常复杂,并导致错误。我想知道是否有一种设计模式或编码方法可以帮助组织逻辑。我使用PHP,但这并不重要。 策略模式似乎具有最大的潜力,但我觉得我需要在策略之上再加上策略。
我想象"业务逻辑"领域可能部分涵盖了这个问题,但搜索并没有找到任何优雅的编码方法。
我并不认为这种问题可以通过某种模式或模式来解决。在某种程度上,这只是“设计”——你构建一个设计,并发现关系和弹性点,在那个时候,面向对象技术(例如)有所帮助,模式才会发挥作用。
多年来,我观察到许多尝试通过“不编写代码”来解决这些问题的尝试。也就是说,我们找到了一些方法将业务逻辑外部化为比代码更易塑造的东西。因此,您可能只需将费用规则外部化:
Thinking 101 Standard $100 Alumni $50 Ex-Military $0
Hard Sums Standard $500 Alumni $100 Ex-Military $0
现在,这些规则的更改是一种配置更改,而不是代码更改。这种数据驱动的方法可能比代码更好。
然后,您想将逻辑外部化,因此规则引擎出现了。
并外部化处理逻辑,因此我们得到了BPEL。
我看到了所有这些方法的成功,但问题在于:实际上您已经将逻辑外部化到某个地方,因此仍然存在两个问题:
这些都是软件,它们真的是伪装成代码。
我认为将几种模式结合使用可能会很有帮助。Fowler的领域模型模式旨在驯服复杂的领域逻辑。另一种选择是使用分层架构模式,就像POSA1中所描述的那样。策略模式似乎也是定义一系列相关算法的好方法。
作为起点,你是否了解单元测试?快速搜索PHP单元测试,可以找到http://www.phpunit.de/。
作为起点,你应该尝试查看是否可以对现有代码进行单元测试。这样,你就可以确信它能够按照预期工作,并且在未来进行更改时不必过于担心破坏现有逻辑。此外,一旦你在现有代码上建立了单元测试,就可以开始进行改进逻辑的更改,并保持同样的信心水平。
应用一些设计模式并不能解决所有问题,但有些模式可以帮助更好地组织代码。如果想要减少错误,那么需要实施某种形式的自动化测试,可以查看测试驱动开发和持续集成方法。