对象是否应该拥有一个基于业务逻辑的属性？

Question

或者，当业务逻辑被激活时，它们应该始终是一个函数吗？

示例：Order.RequiresPayment

属性还是功能？ 有什么时候有商业规则

是否存在可能决定这种情况的模式？

Answer 1

如有疑问，请考虑维护您的代码作为指导。

如果确定OrderRequiresPayment非常简单（例如，在创建订单时设置true，则在收到付款时false），则属性正常。

如果它是由一个公式决定的，或者它是在很多地方更新过的，那么最好将它封装在一个函数中。

Answer 2

这是一个针对特定语言的问题。

例如，在Python中，业务规则可以（通常是）两者。

主要是，它们是方法功能。

然而，Python允许它们作为属性出现，如果在阅读代码时眼睛更容易。

请注意

1. 业务规则通常是方法功能。有时它们是物体之间的关系。方法功能易于扩展和修改。当您需要添加功能并将属性更改为方法功能时，从属性开始是一个错误。

2. 属性最好用作语法糖，使方法函数看起来像属性，因为它使代码更简单或更容易阅读。

Answer 3

通常，属性不应该需要复杂的计算。

属性承诺非常快，而函数（或方法）则不然。因此，计算或可能需要一些时间来检索的值应该是一种方法，并且即时就绪的值可以是属性。

Answer 4

我讨厌的是当对财产的访问导致对象的状态发生变化时。属性应该揭示对象的现有状态，而函数可以用来引起对象的某些变化。

在访问属性时导致对象的状态发生变化会使调试变得非常困难 - 开发人员通常希望某个函数能够导致某些事情发生，并且在使用调试器时不会让函数运行，除非他们已经为结果做好准备。另一方面，大多数调试器将自动访问对象的公共属性，而不仅仅是通过访问属性来改变对象的状态。

Answer 5

您通常可以通过将其视为商业财产或业务职能来决定是否更有意义。抽象的程度并没有改变你对事物的看法。

Answer 6

我同意亚当。通常，属性将包含诸如Count，Length等的值