“getters 和 setters 是邪恶的吗？”视图层失败？
我认为将模型引入视图部分是没有抓住重点的地方。在文章中作者使用构建器来导出模型。问题是：对放入构建器中的内容的控制与使用吸气剂获得的内容一样多。是的，它隐藏了实现，即它在模型中表示的方式。但是吸气剂不会从模型中得到与模型中放入的东西非常不同的东西。如果您创建一个通过构造函数传递“5”的 Money 对象，money.getAmount() 不会返回转换为某种其他货币的值或作为其中包含一个元素“5”的数组。
你设置什么，你就会得到什么。通过视图，我们设置值，以及当我们从一个应该保存我们首先设置的内容的对象中请求（获取）这些值时我们期望的值。出口这些的建筑商也期望同样的结果。
这个问题有点长。但我希望我的观点受到挑战。 getter 和 setter 对于将模型数据传输到视图层来说是否有害？
很多人认为 getter/setter 根本不是邪恶的。这也不是我希望听到的辩护，因为我认为除了我提到的那些地方之外，他们在其他地方确实是邪恶的。
Many people know this article: more on getters and setters. I think it does a convincing job of portraying the evil side of getters/setters. I've also tested it by trying to convert an existing project (unfinished) to code without getters/setters. It worked. Code readability improved greatly, less code and I've even managed to get rid of getters/setters where I initially thought they really were necessary. Except for one place.
Getting models to the view part is where I think this approach misses the point. In the article the author uses a builder to export the model. The problem is: there's just as many control over what is put into the builder as what you would have gotten with getters. Yes it hides the implementation, the way it is represented in the model. But getters don't get out of the model something very different from what was put in there. If you create a Money object passing '5' through the constructor, money.getAmount() won't return this converted to some other currency or as an array with one element '5' in it.
What you set you get. And through the view we set values, and those values we expect when we ask them (get) from an object that is supposed to hold what we set in the first place. A builder to export these just expects the same.
This is a bit long for a question. But I would like to be challenged on my view. Are getters and setters evil for transporting model-data to the view layer?
There are a lot of people who think getters/setters are not evil at all. This is also not what I would like to hear defended, as I think they DO are evil in other places than those I mentioned.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于非常简单的情况，数据对象没有任何要封装的行为，因此基于改进行为封装的参数并不真正适用。
我构建的大多数视图都是事件驱动的。在事件驱动视图中，您可以在模型上注册更改事件，并在模型更改时更新视图，而不是传递“模型”并获取每个属性的值，然后在其状态发生更改时进行更新。鉴于事件机制允许模型将其状态推送到视图，视图不需要 getter 来拉取状态（如果模型也是侦听器，则不需要 builders ）。如果您只更改具有数千个属性的模型中的一个属性，那么构建器并将新模型传递给视图的效果如何？
如果不是将模型视为一组数据，而是将其视为在将状态通知事件从构建器/持久层转发到侦听器/视图时实现缓存，那么很容易看出它的行为它可以被封装，而不是纯粹可以轮询的状态。
For very simple cases, a data object doesn't have any behaviour to encapsulate, so arguments based on improving the encapsulating of behaviour don't really apply.
Most of the views I've built have been event driven. In an event driven view, you register for a change event on the model and update the view when the model changes, rather than passing 'the model' around and getting value of each attribute, then updating if its state has changed. Given that the event mechanism allows the model to push its state to the view, the view doesn't need getters to pull the state ( and if the model is also a listener, you don't need builders ). If you only change one attribute in a model with thousands of attributes, how well would a builder and passing a new model to the view work?
If instead of thinking about a model as a glob of data, but instead think about it as implementing a cache in the forwarding of state notification events from the builder/persistence layer to the listeners/views, then it's easy to see how it has behaviour which can be encapsulated rather than being purely state which can be polled.
有一个替代模型，用于 Scala 语言，但它确实可以在任何地方使用。这是构造函数/提取器模型。构造函数就是类的构造函数。提取器是一种方法，在调用时将返回参数，该参数传递给构造函数，将创建该对象的克隆。
对于动态语言，您只需返回一个列表即可完成。对于静态类型语言，您可以采用对象列表的方式，然后必须对其进行处理，以便可以正确分配每个类型，或者您必须有一个类型参数化的元组类，以便您可以使用正确的类型。
在 Scala 的具体情况下，它的 Extractor 类似于 Java 的静态方法，它们接收一个对象作为输入。它要么返回参数，要么返回
None，它执行类似于 Java 的null的函数。这个想法是你可以分解你所组成的内容，这几乎是视图可能想要的。
现在，您可能有的另一个概念是“告诉，不要问”旨在将业务规则与其适用的数据保持一致。现在，视图的业务规则必然属于视图，因此如果您不反转游戏，您将面临必须向模型询问数据的问题。模型可能告诉视图显示数据，将相关字段传递给它而不是被要求提供它们。因此模型告诉视图显示数据，视图告诉模型更新数据。
There is an alternate model, used in the Scala language, but which can really be used anywhere. It's the Constructor/Extractor model. Constructor is just that, the constructor of a class. The extractor is a method which, when called, will return the parameters which, passed to a Constructor, will create a clone of this object.
For dynamic languages, you just return a list and be done with it. For statically typed languages, you can go the way of a list of objects, which must then be processed to that each type can be correctly assigned, or you must have a type-parameterized tuple class, so that you can return each parameter with the correct type.
In the specific case of Scala, its Extractors are similar to Java's static methods, and they receive an object as input. It either returns the parameters, or it returns
None, which performs a function analogue to Java'snull.The idea is that you can decompose what you composed, which is pretty much what a view might want.
Now, another notion you might have is that "tell, don't ask" intends to keep business rules with the data it applies to. Now, the business rules of a view necessarily belongs with the view, so you are left with the problem of having to ask the model for the data... if you don't invert the game. The model might tell the view to display data, passing the relevant fields to it instead of being asked for them. So the model tells the view to display data, and the view tells the model to update it.