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