视图层的“getter 和 setter 是邪恶的”是否失败？

Question

很多人都知道这篇文章：更多关于 getter 和 setter。我认为它在描绘 getter/setter 的邪恶方面做得很有说服力。我还通过尝试将现有项目（未完成）转换为没有 getter/setter 的代码来测试它。有效。代码可读性大大提高，代码更少，我什至设法摆脱了最初认为它们确实有必要的 getter/setter。除了一处。

让模型进入视图部分是我认为这种方法没有抓住要点的地方。在文章中作者使用构建器导出模型。问题是：对放入构建器的内容的控制与使用 getter 获得的内容一样多。是的，它隐藏了实现，即它在模型中的表示方式。但是 getter 并没有从模型中取出与放入其中的非常不同的东西。如果您创建一个通过构造函数传递 '5' 的 Money 对象，money.getAmount() 将不会将此转换为其他货币或作为其中包含一个元素 '5' 的数组返回。

你设置什么就得到什么。通过视图，我们设置了值，以及当我们从一个应该保存我们首先设置的对象的对象中询问（获取）这些值时我们期望的值。导出这些的构建器只是期望相同。

这个问题有点长。但我想在我的观点上受到挑战。将模型数据传输到视图层的 getter 和 setter 是否邪恶？

有很多人认为 getter/setter 根本不是邪恶的。这也不是我想听到的辩护，因为我认为他们在我提到的其他地方确实是邪恶的。

Answer 1

对于非常简单的情况，数据对象没有任何要封装的行为，因此基于改进行为封装的参数并不真正适用。

我构建的大多数视图都是事件驱动的。在事件驱动视图中，您可以在模型上注册更改事件，并在模型更改时更新视图，而不是传递“模型”并获取每个属性的值，然后在其状态发生更改时进行更新。鉴于事件机制允许模型将其状态推送到视图，视图不需要 getter 来拉取状态（如果模型也是侦听器，则不需要 builders ）。如果您只更改具有数千个属性的模型中的一个属性，那么构建器并将新模型传递给视图的效果如何？

如果不是将模型视为一组数据，而是将其视为在将状态通知事件从构建器/持久层转发到侦听器/视图时实现缓存，那么很容易看出它的行为它可以被封装，而不是纯粹可以轮询的状态。