有复杂逻辑的设计模式/编码方法吗？
我必须清理在线大学申请的代码。没有什么特别的问题，但是很复杂。不同的学位课程有不同的先决条件、费用、所需文件和问题。最重要的是，来自军队的学生会收取不同的费用，而以前的学生则无需支付费用并跳过步骤。
显然，所有这些逻辑都可能变得非常复杂 - 并导致错误。我想知道是否有一种设计模式或编码方法可以帮助组织逻辑。我正在使用 PHP，这并不重要。
策略模式似乎最具潜力，但在我看来我需要策略在此之上的策略。
我想“业务逻辑”领域可能至少部分地涵盖了这一点，但搜索尚未发现任何可以使用的优雅编码方法的迹象。
I had to clean up code for an online college application. There's nothing particularly wrong with it, but it was complicated. Different degree programs had different prequisites, fees, required documentation, and questions. On top of that, students coming from the military get different fees, and previous students pay no fees and skip steps.
Obviously all this logic can get pretty complex - and cause bugs. I'm wondering if there's a design pattern or coding method that would help with organizing the logic. I'm using PHP, not that it matters.
The strategy pattern seems to have the most potential, but it seems to me I'd need strategies on top of strategies for this.
I imagine the field of "Business Logic" might cover this at least partially, but searches haven't turned up indications of any elegant coding methods to use.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不相信这种问题可以通过一种或多种模式来解决。在某种程度上，“只是设计”——您构建一个设计并发现 OO 技术（例如）可以提供帮助的关系和拐点，此时模式就可以发挥作用。
多年来，我观察到许多通过“不编写代码”来解决此类问题的尝试。也就是说，我们找到某种方法将业务逻辑外部化为比代码更具延展性的东西。因此，您可能只是将费用规则外部化：
现在这些规则的更改是配置更改而不是代码更改。这种数据驱动的方法可能比代码更好。
然后你想要外部化逻辑，因此规则引擎出现了。
并将处理逻辑外部化，因此我们得到了 BPEL。
我看到所有这些方法都取得了成功，但是......实际上，您已经将逻辑外化到某个地方，因此仍然存在两个问题：
这东西仍然是软件，它确实是伪装的代码。
I'm not convinced that this kind of problem is addressed by a pattern or patterns as such. To some extent is "just design" - you build a design and discover relationships and flex points where OO techniques (for example) help and at that point patterns come into play.
I've observed over the years many attempts to solve these kinds of problems by "Not Writing Code". That is we find some way to externalise the business logic into something more malleable than code. So it might just be that you externalise the fee rules:
Now changes in these rules are a config change rather than a code change. This kind of data-driven appraoch is probably better than code.
Then you want to externalise logic, and so Rules Engines emerge.
And externalise processing logic and hence we get BPEL.
I see success with all these approaches, but ... in effect you have logic externalised somewhere so two issues remain:
This stuff is still software, it really is code in disguise.
正如您所建议的，策略模式听起来可能很符合要求 - 但如果有相当复杂的逻辑，您会希望将其放入 域模型，而不是事务脚本 您现在可能正在使用。
Fowler 的书 企业应用程序架构模式 对应用程序的整个思考领域进行了很好的解释（他建议你从那里开始并从那里开始工作）。
正如其他人所说，单元测试总是有帮助的！
Stategy pattern, as you suggest, sounds like it might fit the bill well - but with a fair bit of complex logic you'll want to put this in a domain model, and not the transaction script you're probably using now.
Fowler's book Patterns of Enterprise Application Architecture has good explanations of this whole area of thinking about your app (he suggests you start with that and work from there).
And as others have said, unit testing always helps!
我认为模式的组合会很有帮助。 Fowler 的域模型模式旨在驯服复杂的域逻辑。使用分层架构模式是另一种选择，如 POSA1 中所述。策略模式似乎也是定义一系列相关算法的好主意。
I think a combination of patterns would be helpful. Fowler's Domain Model pattern aims to tame complex domain logic. Using a Layered architectural pattern is another option, as described in POSA1. Strategy pattern also seems to be a good idea for defining a family of related algorithms.
首先，您是否遇到过单元测试？快速谷歌搜索 PHP 单元测试后发现 http://www.phpunit.de/。
作为起点，您应该看看是否可以对现有代码进行单元测试。这样，您就可以相信它会实现其预期目的，并且应该能够在未来进行更改，而不必太担心破坏现有逻辑。此外，一旦您对现有代码进行了单元测试，您就可以开始进行更改以以相同的置信度改进逻辑。
As a starting point, have you come across unit testing? A quick google for PHP unit testing came up with http://www.phpunit.de/.
As a starting point you should look to see if you can unit test your existing code. That way you have confidence that it does what it's meant to and should be able to make changes in the future without worrying so much about breaking existing logic. Also once you've got unit tests in place on existing code you can beging to make changes to improve the logic with same level of confidence.
应用某些设计模式并不能解决所有问题，尽管某些设计模式可能有助于更好地组织代码。如果您想减少错误，请实施某种自动化测试，请查看测试驱动开发和持续集成方法。
Applying some design patterns won't solve all of your problems, though some may help to better organize the code. If you want to reduce bugs, then implement some sort of automated testing, look at the Test Driven Development and Continuous Integration methodologies.