OO 程序与业务规则变化
我正在维护一个定制的、高度面向对象的电子商务应用程序。最初的设计师做了一些假设，例如： - 销售税的种类绝不会超过 3 种（州税、国民税和统一税） - 每种类型的销售税只能有一个税率。 - 每个州都将被分配三种税种之一。
他应该更清楚，但我想这在当时似乎是合理的……突然之间，每个州都设定了自己的“统一”税率。
问题：在对象堆栈的下 3 层，我有一个仅使用金额和税收类型的税收计算方法。现在我面临着对应用程序进行相当大的重组的任务，我对此知之甚少，也没有多少预算来学习
我倾向于将状态代码填充到会话值中，并在另一端进行一些硬编码计算。 （1 天）而不是重组（1-2 周？？）
这是我的想象还是 OO 应用程序有更大的学习曲线并且当业务规则发生意外转变时可能更难维护？
I am maintaining a custom built and highly OO e-commerce application. The original designer made a few assumptions like:
- there will never be more than 3 types of sales tax (state, national & hamonized)
- each type of sales tax can have only one rate.
- each state will be assigned one of the three tax types.
He should have known better, but I guess it seemed reasonable at the time... All of a sudden each state is settings its own "harmonized" tax rate.
Problem: 3 levels down the object stack, I have a tax calculation method that uses only amount and tax type. Now I am faced with the task of a pretty big restructure of a application that I have little understanding or little budget to learn
I am inclined to stuff the state code into a session value and do a bit of hard-coded calculations on the other end. (1 day) instead of a re-structure (1-2 weeks??)
Is it my imagination or do OO applications have a bigger learning curve and can be harder to maintain when the business rules take an unexpected turn?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有点。我认为曲线更陡，但比用功能代码构建的应用程序短得多。 OO 应用程序更有可能遵循模式，遵守某种编码标准，并向应用程序添加结构或框架。而函数式代码则可以更自由地随心所欲地执行，只要最终结果是一个可用的产品。这为开发人员创造了一个成熟的环境，可以让他们摆脱意大利面条式代码的心态。
视情况而定。但无论使用何种编码风格，这都可能是正确的。就您而言，这似乎是正确的。然而，从历史上看，OOP 和模式使经验丰富的程序员更容易维护应用程序，而不是完全由意大利面条、函数式代码编写的应用程序。
Somewhat. I consider the curve to be steeper, but much shorter than an app built in functional code. An OO app is more likely to follow patterns, adhere to some kind of coding standard, and add structure or a framework to an application. While functional code is much more free to do as it pleases so long as the end-result is a working product. This produces an environment ripe for developer(s) to circum to the spaghetti-code mentality.
Depends. But this could be true regardless of the coding style used. In your case, this would appear true. However, OOP and patterns, historically, have made it easier for experienced programmers to maintain an application vs one written entirely of spaghetti, functional, code.