我进入了一个关于 getter 和 setter 方法和封装的有趣的互联网争论。有人说他们应该做的只是一个赋值（setter）或一个变量访问（getter）来保持它们“纯”并确保封装。
在您将此问题作为重复项关闭之前：我在这里花了很多时间搜索，但没有找到这些特定问题的任何答案。如果你能告诉我一个回答他们的问题，我很乐意删除这个问题。
我完全同意；尽管我会说验证是访问者合法业务的一部分——尤其是二传手！允许未经验证的设置器是非常糟糕的做法。
传播无效数据的对象意味着您必须担心其外部的属性，这严重破坏了封装。
如果未经检查的访问器有正当理由，请同时提供，命名get等unchecked_Get，以明确哪个是首选，按照Unchecked_Access我首选的面向对象语言的思路。
只是重新阅读 Fowler 的“重构”，他认为只有原始访问器的类可能应该删除并重构为没有任何价值。
具体答案：（我的看法）
是的，它会破坏访问者的目的；这几乎和公开实例变量一样糟糕......
最好在施工和设置上进行验证；那么您可以信任该对象。
设置器可以更改值吗？我认为您必须根据具体情况做出决定。在某些细节上，一般的答案是错误的。有时你希望 setter 失败并指出潜在的问题，让你修复它。
我是否正确，这将完全违背首先拥有 getter 和 setter 的目的，并且应该允许验证和其他逻辑（当然没有奇怪的副作用）？
是的。如果您正在获取和设置，那很好，因为您将来可以引入锁或转换例程，但如果您永远不需要它，只需将成员公开！
什么时候应该进行验证？设置值时，在 setter 内部（以保护对象永远不会进入无效状态 - 我的观点）在设置值之前，在 setter 外部 在对象内部，每次使用该值之前
这取决于你。预先评估和验证所有内容称为摊销，这很好，因为您知道状态始终有效。但是，如果您更愿意稍后再做，则称为延迟验证，如果您从未真正使用过数据，它可以提高性能。
是否允许设置器更改值（可能将有效值转换为某些规范表示）？
当然，这是使用它们的一个很好的理由。如果您突然需要支持两种类型的输入（例如，公制和标准），您可以在一处将逻辑添加到设置器，而不是在整个项目中更改其使用的每个实例。