如何对进行计算和存储的类进行建模？ [英] How to model classes that do calculations and store them?

问题描述

我必须开发一个财务应用程序的一部分，它接收两个属性并返回两个结果。在你认为它不是一个类，但是方法之前，我不得不说，我必须坚持：两个用户提供的参数和两个输出。让我们在这个模拟中说明如下：

I have to develop a class, part of a financial application, which receives two properties and returns two results. Before you think that it is not a class, but method(s), I have to say that I have to persist both: the two user-provided parameters and the two outputs. Let's illustrate like follows in this mock:

 ----------------
|PetWash         |
|----------------|
|petWeight       |<- user provided
|petHeight       |<- user provided
|ammountSoapUsed |<- system calculated
|price           |<- system calculated
 ----------------

1. 我应该在模型类中进行计算吗？例如，表示此实体的相同模型类应该包含进行这些计算的方法？或者我应该创建一种计算引擎，它将返回数据并将其存储在计算的字段中？

1. Should I do calculations in model classes? eg., the same model class that represents this entity should enclose the methods that do these calculations? Or should I create a kind of "calculation Engine" that would return data and store it in calculated fields?

如果第一种情况，我应该调用计算getter方法或只是创建一个计算方法来更新ammountSoapUsed的价值和价格？在这个意义上，我应该只是存储petWeight和petHeight，并且在每次需要的时候计算ammountSoapUsed和价格（记住，在现实生活中，计算复杂得多）？

If the first case, should I invoke calculations in the getter methods or just create a "calculate" method which would update the value for ammountSoapUsed and price? In this sense, should I just store petWeight and petHeight and calculate ammountSoapUsed and price everytime that they are needed (remember that in the real-life case calculation is much more complex)?

事实上，我对我能做什么不感兴趣，但是在什么OOP最佳实践中建议做。你可以帮助我吗？

In truth, I'm not interested in what I could do, but in what OOP best practices recommend to do. Can you help me?

推荐答案

理想的面向对象方法首先从问题域的分析开始。 PetWash 听起来不像问题域名概念，听起来像是发生宠物洗涤事件的记录，或是您将提供给宠物洗涤的估计顾客。这是什么？清楚。

The ideal object oriented approach starts with an analysis of the problem domain. PetWash does not sound like a problem-domain concept, it sounds like the record of a pet washing event that occurred, or an estimate for a pet washing that you will offer to a customer. Which is it? Be clear.

1. 模拟问题域以更好地了解信息和操作要求。课程必须与问题领域的现实世界产生共鸣。 CalculationEngine 当然不符合这个标准。课程肯定可以做计算，但是他们应该向非技术人员提供可识别的商业价值。假设目的是为潜在客户提供估计，对我而言是一个客户类的实例，链接到动物类，其中每个都有一个高度和 weight 。链接到客户类的实例可能是链接到<$ c的实例的 Estimate 类的实例$ c>动物待洗。等等。

1. Model the problem domain to better understand the information and operation requirements. Classes must resonate with the real world of the problem domain. CalculationEngine certainly doesn't fit this criterion. Classes can certainly do calculations, but they should provide business value recognizable to a non-technical business person. Assuming the purpose is to provide an estimate for a potential customer, what makes sense to me is an instance of a Customer class that links to multiple instances of an Animal class, where each has a height and weight. Linked to an instance of a Customer class might be instances of an Estimate class that links to instances of the Animal to be washed. And so on.

你的问题太低级别。你不应该在getter中调用计算，也不应该提供一个 calculate（）操作。专注于对非技术性业务人员有意义的操作。再次，假设您提供估算，请为客户的实例提供操作，添加或更新他/她的动物。在给予一个或多个客户的动物时，提供一个提供估计的操作。 Estimate 封装了规则和计算。如果客户同意估算，您可以使用它来管理您的肥皂库存或其他。将实现隐藏在这个问题域外观之后，以便在（不需要）您需要时，可以交换一个坏的实现。

Your question is too low-level. You should neither invoke calculations in getters nor provide a calculate() operation. Focus on operations that would make sense to a non-technical business person. Again, assuming you are providing an estimate, provide operations on an instance of a Customer that add or update his or her Animals. Provide an operation that provides an Estimate when given one or more of the customer's Animals. That Estimate encapsulates the rules and calculations. If a Customer agrees to an Estimate, you can use that to manage your soap inventory or whatever. Keep the implementation hidden behind this problem-domain facade so you can swap out a bad implementation when (not if) you need to.

我看到的大多数OO代码完全解决了问题领域，似乎在尝试敏捷的同时，在口香糖和胶带中构建应用程序。问题领域的一个很好的模型是比较耐用的。形成鲜明对比的是，解决方案领域的重点（管道设计）不耐用，并且是成本超支，昂贵的重新工作和取消的项目的原因。不要让你的项目之一！

Most of the OO code I've seen these days dismisses the problem domain altogether and seems to build applications out of chewing gum and duct tape while trying to be agile. A good model of the problem domain is relatively durable. In stark contrast, a focus on the solution domain (a duct-taped design de jour) is not durable and is the cause of much cost overrun, expensive re-work, and canceled projects. Don't make your project one of those!

这篇关于如何对进行计算和存储的类进行建模？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！