5

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

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

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

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

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

4

2 回答 2

3

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

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

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

于 2009-08-20T18:52:27.870 回答
1

Scala 语言中使用了另一种模型，但它确实可以在任何地方使用。它是构造器/提取器模型。构造函数就是这样，一个类的构造函数。提取器是一种方法，当被调用时，将返回参数，传递给构造器，将创建该对象的克隆。

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

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

这个想法是你可以分解你组成的东西，这几乎是视图可能想要的。

现在，您可能有的另一个概念是“告诉，不要问”旨在将业务规则与它适用的数据一起保留。现在，视图的业务规则必然属于视图，所以你不得不向模型询问数据的问题......如果你不反转游戏。模型可能会告诉视图显示数据，将相关字段传递给它，而不是被要求提供它们。所以模型告诉视图显示数据，视图告诉模型更新它。

于 2009-08-20T19:07:48.710 回答