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

Question

或者它们应该始终是一个功能，当业务逻辑invloved？

实施例：Order.RequiresPayment

性质或功能？ 有什么业务规则至于它是否为真

有没有一种模式可以确定这一点？

Answer 1

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

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

如果它是由一个公式确定的，或者如果它在很多地方进行了更新，最好将它封装在一个函数中。

Answer 2

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

例如，在Python中，业务规则可以（并且通常是）都可以。

原则上，它们是方法函数。

但是，Python允许它们作为属性显示，如果阅读代码时眼睛更容易。

注意

1. 业务规则是 - 一般 - 方法的功能。有时他们是对象之间的关系。方法功能很容易扩展和修改。当您需要添加功能并将属性更改为方法功能时，从属性开始是一个错误。

2. 属性最适合作为语法糖使方法函数看起来像一个属性，因为它使代码更简单或更易于阅读。

Answer 3

您通常可以根据将其视为业务属性还是业务功能来判断它是否更有意义来决定。抽象层次不会改变你对事物的看法。

Answer 4

我同意亚当。通常，属性将包含诸如计数，长度等的值。

Answer 5

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

属性承诺速度非常快，而函数（或方法）则没有。因此，计算出的值或可能需要一些时间来检索的值应该是一种方法，并且即时准备好的值可以是一个属性。

Answer 6

我的宠物讨厌是当访问属性导致对象的状态改变。属性应该揭示一些关于对象的现有状态的东西，而函数可以用来引起关于对象改变的事情。

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