oo 程序与业务规则的变化

Question

我正在维护一个自定义构建且高度 OO 的电子商务应用程序。最初的设计师做了一些假设，例如： - 永远不会有超过 3 种类型的销售税（州、国家和统一） - 每种销售税只能有一个税率。 - 每个州将被分配三种税收类型之一。

他应该知道得更多，但我想这在当时似乎是合理的......突然之间，每个州都设置了自己的“统一”税率。

问题：对象堆栈向下 3 层，我有一个仅使用金额和税种的税款计算方法。现在，我面临着对应用程序进行相当大的重组任务，而我对此了解甚少或预算不足

我倾向于将状态代码填充到会话值中，并在另一端进行一些硬编码计算。 （1 天）而不是重组（1-2 周？？）

是我的想象还是 OO 应用程序的学习曲线更大，当业务规则发生意外转变时可能更难维护？

Answer 1

是我的想象还是面向对象应用的学习曲线更大...

有点。我认为曲线更陡峭，但比内置功能代码的应用程序短得多。 OO 应用程序更有可能遵循模式，遵守某种编码标准，并向应用程序添加结构或框架。只要最终结果是可以工作的产品，功能代码就可以随心所欲地做更多的事情。这为开发人员提供了一个成熟的环境来规避意大利面条代码的心态。

...当业务规则发生意外转变时，可能更难维护？

视情况而定。但无论使用何种编码风格，这都是正确的。在您的情况下，这似乎是正确的。然而，从历史上看，OOP 和模式让有经验的程序员更容易维护应用程序，而不是完全由意大利面条、函数式代码编写的应用程序。