视图图层的'getters and setters是邪恶'失败吗？

Question

很多人都知道这篇文章：more on getters and setters。我认为它描绘了吸气者/定居者的邪恶一面是令人信服的工作。我还通过尝试将现有项目（未完成）转换为没有getter/setter的代码来测试它。有效。代码可读性大大提高，代码更少，我甚至设法摆脱了我最初认为他们确实需要的getter/setter。除了一个地方。

将模型导入视图部分是我认为这种方法忽略了重点的地方。在文章中，作者使用构建器来导出模型。问题在于：对建筑师投入的内容与对于获得者所获得的内容的控制一样多。是的，它隐藏了实现，它在模型中的表现方式。但是吸气者并没有脱离那种与放在那里的东西截然不同的东西。如果您通过构造函数创建传递'5'的Money对象，则money.getAmount（）不会将此转换为其他货币或具有一个元素'5'的数组。

你设定了什么。通过这个观点，我们设定了价值观，以及当我们从一个本应该保持我们首先设定的目标的对象那里得到（获得）的价值。一个建造者出口这些只是期望相同。

这个问题有点长。但我想对我的观点提出质疑。为了将模型数据传输到视图层，getter和setter是否是邪恶的？

有很多人认为getters/setters根本就不是邪恶的。这也不是我想要听到的辩护，因为我认为他们在除了我提到的那些地方以外的其他地方都是邪恶的。

Answer 1

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

我构建的大部分视图都是事件驱动的。在事件驱动视图中，您注册模型上的更改事件，并在模型更改时更新视图，而不是传递“模型”并获取每个属性的值，然后更新其状态是否已更改。假设事件机制允许模型将其状态推送到视图，则视图不需要获取者来获取状态（如果模型也是一个侦听器，则不需要构建器）。如果您只更改具有数千个属性的模型中的一个属性，则构建器和将新模型传递给视图的效果如何？

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

Answer 2

在Scala语言中有一个替代模型，但它可以在任何地方使用。这是构造器/提取器模型。构造函数就是这样一个类的构造函数。提取器是一种被调用的方法，它将返回传递给构造器的参数，以创建该对象的一个​​副本。

对于动态语言，您只需返回一个列表并完成它。对于静态类型语言，您可以使用对象列表的方式，然后对其进行处理，以便可以正确分配每种类型，或者必须具有类型参数化的元组类，以便您可以返回每个参数正确的类型。

在Scala的特定情况下，它的提取器类似于Java的静态方法，它们接收一个对象作为输入。它要么返回参数，要么返回None，它执行Java的null的功能模拟。

这个想法是，你可以分解你创作的东西，这几乎是一个视图可能需要的东西。

现在，您可能需要的另一个概念是“告诉，不问问”打算保留其适用的数据的业务规则和。现在，视图的业务规则必然属于视图，因此如果不反转游戏，则需要为模型提供数据的问题。该模型可能会告诉视图来显示数据，将相关字段传递给它，而不是被要求。所以模型告诉视图显示数据，视图告诉模型进行更新。