在属性中实现逻辑是一个好的实践吗

属性访问应该是即时的(无长时间等待)、一致的(无更改的值)和安全的(无异常)。如果你能做出这些保证,我认为在属性中加入逻辑是可以的。

有了它就好了 一些 属性中的逻辑。例如,setter中的参数验证和getter中的延迟计算都是相当常见的。

它是 通常 但是,对于属性访问来说,做一些昂贵的事情是一个坏主意,比如数据库调用。开发人员倾向于假设房地产的估价相当便宜。

最后,这是一个判断调用——但我当然拒绝了这样的建议:属性应该只在可以用自动属性实现的程度上是微不足道的。

Properties are methods . 他们只不过是盖特人/二传手的捷径。任何在getter/setter中有效的逻辑都可以放入属性中。您通常不会放入getter/setter中的任何逻辑都不适合放入属性中。一般来说,如果您(作为类的消费者)不能真正期望设置属性值,或者更糟的是,获取属性值可能会导致行为发生,那么该逻辑可能属于其他地方。换句话说,逻辑应该是相关的,并且与获取或设置属性一致。

引用上述链接文章:

属性是提供 灵活的读、写或 计算私有字段的值。 属性可以像 是公共数据成员,但它们是 实际上调用了特殊方法 访问器。这使得数据 在提供 方法的安全性和灵活性。

这里有一个常见的答案:视情况而定。

一般来说,实施 商业 getter和setter中的逻辑。如果您的对象是一个简单的DTO(数据传输对象),这将违反单一责任。

然而,状态跟踪逻辑和其他内务管理经常在属性中发现。例如,实体框架4自跟踪实体在每个基本属性设置器中都有状态管理逻辑,以允许跟踪。

属性中逻辑的另一种选择是面向方面编程(AOP)。使用AOP,可以在对象和宿主进程之间“注入”逻辑。对对象的访问可以被“拦截”并有条件地处理。

如果需要使用JSON、XML或ORM对对象进行序列化/反序列化,那么将业务逻辑放在setter中可能会遇到麻烦。例如,在使用NoSQL数据存储时,如文档数据库或ORM。其中一些(例如NHibernate)可以配置为访问支持字段而不是setter。

我发现使用一个公共getter和私有setter以及一个方法来根据需要使用额外的逻辑设置值是一种很好的方法。大多数序列化程序都可以访问私有的setter,因此最终得到的是持久化对象的精确表示,而不会意外触发逻辑,在反序列化时可能会错误地更改值。

但是,如果您认为不需要序列化/反序列化,那么这不应该是一个问题。

在我看来,这完全没问题。在我看来,首先将属性作为语言特性的唯一理由是,您可以在属性中包含逻辑。否则,您也可以直接访问基础数据成员。

通常情况下,属性只影响1个变量,因为它主要是为此目的而生成的。但有时,您需要一个更高级别的属性,而不仅仅是一个1对1的变量。所以,在这种情况下,它通常会包含代码。但是您必须记住,属性并不是用来作为函数使用的。当你调用一个函数时,你知道它会做一些处理。当你调用一个属性时,你期望它是快速的。

但最后,这是一个偏好的问题,就像编码标准一样,遵循你的上级告诉你的,由你自己决定。所以这并不坏,取决于你的判断力。

在我看来,只有在某些情况下,才允许在setter/getter中使用业务逻辑。例如:把负责验证输入的逻辑放在一起是很荣幸的,因为设置程序负责维护对象状态,这样就不应该违反状态。所以您应该将业务逻辑削减到只负责一个主题的代码的最小部分。

另一件事是你的班级应该是(最好的情况下)波科。为什么?因为它应该是可重用的,并且当类在属性中包含逻辑时,可重用性可以简单地被阻塞。认为你有 SqlServerPerson 如果在属性中进行一些SQLServer验证,则很难将其替换为例如 NHibernatePerson 当您更改ORM/DB访问时。