设计问题：在识别我的课程时遇到问题

我在金融行业的OOP项目中处于中途位置，我正在回顾我的设计决策。我已经使用模式解决了一些问题，我对这些问题感到特别自豪，但在其他地方我似乎缺乏一些严谨。我自己的使用情况是非常高的水平，因为用户完成的实际输入甚至与在机柜底部完成的计算的复杂度相比。为了给你一个想法，我必须同时集成第三方数学求解器和整个解析器，以允许用户输入他自己的公式。设计问题：在识别我的课程时遇到问题

碰巧我有一个很好的二十几类，全称为以同样的方式：计算器，无论

我最初的问题是，我没有明确和独特的域对象从工作（除解析模块，例如）。从对象的角度来看，我有很大的困难 - 程序编写程序本来会容易得多，因为基本上我们只是用金钱或百分比来达到新的金额和百分比。我想不出计算器以外的任何其他实体......计算各种权重或金额。一切似乎是一个巨大的算法涉及$$

我的问题是如何在对象中的对象不能自然地在领域模型或用例中找到？

来源

2010-03-03 Andrei Tanasescu

我一直发现最自然的方法就是试着理解你能以什么方式推广像（或类似的）对象。在某种程度上，你通过制作特殊案例来完成艰苦的工作，现在你只需要寻找相似之处。

例如，您的计算器类的所有计算器类（除了名称）的相似程度如何？他们是否同样初始化？他们是否都有“calculateTax”方法？他们是否都共享一套较低级别的计算？如果你可以抽象你的计算结构，那么你的多个类将自然建模为这些类的特例。

来源

2010-03-03 01:23:50

我所做的是把所有这些常见的责任都放在一个超类中......现在我正在考虑将其重构，因为每个子类只使用它继承的少数几个方法。所以，如果我理解正确，那么你所建议的是通过类似的重构来进行。 – 2010-03-03 01:32:17

如果你的子类只继承了超类的一小部分，这是一个类层次结构被破坏的迹象。您也可以将类似方法的组建模为接口。对于“代码气味”的Web引用可能比引用模式更有用，因为它可能是一个更好的指南，而不是模式，它可能看起来太抽象了。 http://www.codinghorror.com/blog/2006/05/code-smells.html是一个很好的参考，它有一些额外的链接到更多的资源。 – 2010-03-03 01:55:17

您可以将计算器本身视为您的域模型中的抽象实体。接下来应用策略设计模式来处理各种计算算法。一旦CalculatorStrategy到位，U可以使用其他模式，如装饰者，建设者来获得你想要的。

来源

2010-03-04 13:28:49 user1132593

设计问题：在识别我的课程时遇到问题

回答

相关问题