我必须开发一个类，它是财务应用程序的一部分，它接收两个属性并返回两个结果。在你认为它不是一个类，而是方法之前，我不得不说我必须坚持两个：两个用户提供的参数和两个输出。让我们在这个模拟中说明如下：
----------------
|PetWash |
|----------------|
|petWeight |<- user provided
|petHeight |<- user provided
|ammountSoapUsed |<- system calculated
|price |<- system calculated
----------------
我应该在模型类中进行计算吗？例如，表示此实体的同一模型类应该包含执行这些计算的方法吗？或者我应该创建一种“计算引擎”来返回数据并将其存储在计算字段中？
如果是第一种情况，我应该在getter方法中调用计算还是只创建一个“calculate”方法来更新ammountSoapUsed和price的值？从这个意义上说，我应该只存储petWeight和petHeight并计算每次需要时的ammountSoapUsed和价格（请记住，在现实案例中计算要复杂得多）？
事实上，我对我能做的事情不感兴趣，但是对于OOP最佳实践建议做什么。你能救我吗？
答案 0 :(得分：3)
理想的面向对象方法首先分析问题域。 PetWash听起来不像是一个问题领域的概念，它听起来像是发生的宠物洗涤事件的记录，或者是您将向顾客提供的宠物洗涤的估计。这是什么？要清楚。
对问题域进行建模，以便更好地了解信息和操作要求。类必须与问题域的现实世界产生共鸣。 CalculationEngine当然不符合这个标准。类当然可以进行计算，但它们应该为非技术业务人员提供可识别的业务价值。假设目的是为潜在客户提供估算，对我来说有意义的是Customer类的实例，该实例链接到Animal类的多个实例，其中每个实例都有{{1} }和height。链接到weight类的实例可能是Customer类的实例，该类链接到要清洗的Estimate的实例。等等。
你的问题太低了。您既不应该在getter中调用计算，也不应该提供Animal操作。专注于对非技术业务人员有意义的操作。同样，假设您提供估算值，请在calculate()的实例上提供添加或更新其Customer的操作。在给定一个或多个客户Animals时，提供提供Estimate的操作。 Animals封装了规则和计算。如果Estimate同意Customer，您可以使用它来管理您的肥皂库存或其他任何内容。将实现隐藏在此问题域外观之后，这样您就可以在需要时（而不是如果）更换错误的实现。
这些天我见过的大多数OO代码都完全驳回了问题领域，并且似乎在尝试敏捷时用口香糖和胶带来构建应用程序。问题域的良好模型相对持久。与之形成鲜明对比的是，对解决方案领域（管道式设计设计）的关注不耐用，并且是导致成本超支，昂贵的返工和取消项目的原因。不要让你的项目成为其中之一！