很多人都知道这篇文章:more on getters and setters .我认为它在描绘 getter/setter 的邪恶方面做得很有说服力。我还通过尝试将现有项目(未完成)转换为没有 getter/setter 的代码来测试它。有效。代码可读性大大提高，代码更少，我什至设法摆脱了我最初认为它们确实有必要的 getter/setter。除了一处。
让模型进入 View 部分是我认为这种方法没有捕获要点的地方。在文章中作者使用构建器导出模型。问题是:对放入构建器的内容的控制与使用 getter 获得的内容一样多。是的，它隐藏了实现，即它在模型中的表示方式。但是 getter 并没有从模型中取出与放入其中的非常不同的东西。如果您创建一个通过构造函数传递 '5' 的 Money 对象，money.getAmount() 将不会将其返回转换为其他货币或作为其中包含一个元素 '5' 的数组。
你设置什么就得到什么。通过 View ，我们设置了值，以及当我们从一个应该保存我们首先设置的对象的对象中询问(获取)这些值时我们期望的值。导出这些的构建器只是期望相同。
这个问题有点长。但我想在我的观点上受到挑战。将模型数据传输到 View 层的 getter 和 setter 是否邪恶？
有很多人认为 getter/setter 根本不是邪恶的。这也不是我想听到的辩护，因为我认为他们在我提到的其他地方确实是邪恶的。
最佳答案
对于非常简单的情况，数据对象没有任何要封装的行为，因此基于改进行为封装的论点并不真正适用。
我构建的大多数 View 都是事件驱动的。在事件驱动 View 中，您在模型上注册更改事件并在模型更改时更新 View ，而不是传递“模型”并获取每个属性的值，然后在其状态更改时更新。鉴于事件机制允许模型将其状态推送到 View ， View 不需要 getter 来拉取状态(如果模型也是监听器，则不需要 builders )。如果您只更改具有数千个属性的模型中的一个属性，构建器和将新模型传递给 View 的效果如何？
如果不是将模型视为一团数据，而是将其视为在将状态通知事件从构建器/持久层转发到监听器/ View 时实现缓存，那么很容易看出它的行为方式它可以被封装，而不是可以被轮询的纯粹状态。
关于model-view-controller - View 层的 'getters and setters are evil' 是否失败？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1307796/