我正在维护一个定制的高度OO电子商务应用程序。原设计师做了一些假设，如： - 永远不会有超过3种销售税（州，国家和官方） - 每种销售税只能有一种税率。 - 每个州将被分配三种税种之一。
他本应该知道的更好，但我想当时这似乎是合理的......突然之间，每个州都设定了自己的“统一”税率。
问题：对象堆栈中有3个级别，我有一个仅使用金额和税收类型的税收计算方法。现在我面临着一个相当大的应用程序重组的任务，我对它的理解很少或预算不足
我倾向于将状态代码填充到会话值中，并在另一端进行一些硬编码计算。 （1天）而不是重组（1-2周??）
是我的想象力还是OO应用程序有更大的学习曲线，并且在业务规则出现意外转变时难以维护？
答案 0 :(得分：0)
是我的想象力还是OO应用程序有更大的学习曲线......
有点。我认为曲线更陡峭，但比功能代码中构建的应用程序短得多。 OO应用程序更可能遵循模式，遵循某种编码标准，并为应用程序添加结构或框架。虽然功能代码可以随意使用，但只要最终结果是工作产品就可以。这为开发人员提供了一个成熟的环境，以适应意大利面条代码的心态。
...当业务规则发生意外转变时，可能难以维护吗？
取决于。但无论使用何种编码方式，这都可能成立。在你的情况下，这似乎是真的。但是，从历史上看，OOP和模式使有经验的程序员更容易维护一个应用程序，而不是一个完全由意大利面，功能代码编写的程序。