我有一个最好的实践/设计模式问题。我正在调度我需要计算价格的调度系统。
在系统设置中，管理员可以管理8种不同的费率规则。有一个最低费用，停车，收费，....
每个规则都可以激活和停用，每个规则都有自己的参数， 例如规则＆＃39;停车＆＃39;有参数＆＃39;价格＆＃39;，＆＃39;增值税＆＃39;，＆＃39;每小时价格或固定价格＆＃39;，...
我正在考虑使用策略模式或Bridge模式，但我认为两者都不合适。
另一种解决方案是不使用接口的简单继承。
我已经建模了一些东西，但我对结果并不百分百满意：
https://www.dropbox.com/s/jllb8h0671ssq8u/RateRule-Pattern.png
答案 0 :(得分：0)
听起来很合理...... 无论你称之为什么样的模式，我都会在你的想法中看到很多意义 - ParkingCalculator，TollCalculator等的集合，带有一个通用界面。这样可以轻松添加更多类型的付款，如果它们沿途弹出，它允许您替换一些部分（例如不同的停车政策）。如果后者发生，那么它确实属于“战略”的经典定义。
我个人也将它隐藏在“calculateTotal”的更高级别界面后面 - 当前实现“迭代一系列计算器”，但系统的其余部分不应该'请注意，如果这种情况发生变化（例如，如果规则变得如此复杂，以至于要求运输部要求树或REST调用某些外部服务）。
