Php 面向对象程序与业务规则的变化
我正在维护一个定制的、高度面向对象的电子商务应用程序。最初的设计师做了一些假设，如： -销售税的种类永远不会超过3种（州、国家和民族） -每种类型的销售税只能有一个税率。 -每个州将被分配三种税种中的一种 他应该知道得更清楚，但我想当时这似乎是合理的。。。突然之间，每个州都在设定自己的“统一”税率 问题：在对象堆栈的下面3层，我有一个只使用金额和税类型的税计算方法。现在，我面临着对一个应用程序进行大规模重组的任务，而我对这个应用程序几乎不了解，也没有多少预算需要学习 我倾向于将状态代码塞入会话值，并在另一端进行一些硬编码计算。（1天）而不是重组（1-2周？？） 这是我的想象，还是OO应用程序有更大的学习曲线，并且在业务规则发生意外变化时更难维护 是我的想象还是OO应用程序有更大的学习曲线Php 面向对象程序与业务规则的变化,php,business-logic,oop,Php,Business Logic,Oop,我正在维护一个定制的、高度面向对象的电子商务应用程序。最初的设计师做了一些假设，如： -销售税的种类永远不会超过3种（州、国家和民族） -每种类型的销售税只能有一个税率。 -每个州将被分配三种税种中的一种 他应该知道得更清楚，但我想当时这似乎是合理的。。。突然之间，每个州都在设定自己的“统一”税率 问题：在对象堆栈的下面3层，我有一个只使用金额和税类型的税计算方法。现在，我面临着对一个应用程序进行大规模重组的任务，而我对这个应用程序几乎不了解，也没有多少预算需要学习 我倾向于将状态代码塞入会话值
有点。我认为曲线更陡峭，但比在功能代码中构建的应用程序要短得多。OO应用程序更可能遵循模式，遵循某种编码标准，并向应用程序添加结构或框架。而函数代码则更自由，只要最终结果是一个工作产品，就可以随心所欲地执行。这为开发人员提供了一个成熟的环境，使他们能够绕过意大利面条式的代码思维 …而且当业务规则发生意外变化时，维护起来会更加困难
视情况而定。但无论使用何种编码风格，这都可能是正确的。在你的情况下，这似乎是真的。然而，OOP和模式，历史上，使经验丰富的程序员更容易维护一个应用程序，而不是完全由意大利面，功能，代码。< /P>“有点。我认为曲线更陡峭，但比功能代码内置的应用程序要短得多。”比什么更陡峭？陡峭意味着理解OO应用程序更困难，但所需时间更少。一个功能型的应用程序可能不需要花费太多的努力就能立即理解，但完全接受它可能需要更多的时间。这两种情况都假设开发人员一开始对产品一无所知。