视图层的“getter和setter是邪恶的”失败了吗?

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

我构建的大多数视图都是事件驱动的。在事件驱动视图中,您可以在模型上注册更改事件,并在模型更改时更新视图,而不是到处传递“模型”并获取每个属性的值,然后在其状态更改时进行更新。假定事件机制允许模型将其状态推送到视图中,则视图不需要getter来拉取状态(如果模型也是侦听器,则不需要构建器)。如果在一个具有数千个属性的模型中只更改一个属性,那么构建器和向视图传递新模型的工作效果如何?

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

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

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

None ,它执行类似于Java的功能 null

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

现在,你可能有另一个想法,“告诉,不要问”是为了遵守业务规则 具有 它所应用的数据。现在,视图的业务规则必然属于该视图,因此您将不得不向模型请求数据。。。如果你不改变游戏规则。模型可能 显示数据的视图,将相关字段传递给该视图,而不是要求它们。所以模型告诉视图显示数据,视图告诉模型更新数据。