我可以使用没有 getter 和 setter 的 mvc 吗？
如果我不想公开对象的状态，但仍然需要显示它（例如，以 HTML、XML 或 JSON 的形式），我将如何在 MVC 环境中做到这一点。 使用导出方法来导出简化的不可变对象（如果愿意的话，可以称为“数据类”）是否有意义。 添加与接口对话的渲染方法怎么样？ 还有其他方法可以解决这个问题吗？
If I don't want to expose the state of my object, but I still need to display it (in HTML, XML or JSON let's say), how would I go about doing that in an MVC environment.
Does it make sense to have an export method which exports a dumbed down immutable object (a "data class" if you will).
What about adding in a render method which talks to an interface?
Are there any other approaches to this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
渲染方法最接近不暴露状态。 另一种方法（Smarty 用户熟知）是向视图提供非对象数据结构以供使用。
不过，值得一问的是，这些抽象和/或它们所服务的接口隐藏正在解决什么问题？ 如果你要完成所有这些工作，我认为你应该确保它可以为你节省一些工作。
The render method comes the closest to not exposing state. Another method (well-known to Smarty users) is to feed the view non-object data structures to work with.
It's worth asking, though, what is the problem that these abstractions and/or the interface hiding they serve are solving? If you're going to be doing all this work, IMO you should make sure there's some work it's saving you.
封装的要点是隐藏实现。 其他对象确实需要了解一些“状态”——有时对象的整个目的就是告诉这种状态。
例如，如果定义的有限自动机对象没有 getter 来判断它是否处于最终状态，那么它是毫无用处的。 但封装这些信息在内部的存储方式确实很有用。
现在，getter 和 setter 的目标是提供一个对象状态属性的接口，这可能与它的实际实现方式没有任何关系。 诚然，大多数时候这些属性是对象中的字段，而 getter 和 setter 只是浅层外壳。 另一方面，您可以自由地更改内部实现，因为 getter 和 setter 将确保接口兼容性。
但是，如果这些属性与实际实现太相关，而与对象的内容关系不大，那么您应该考虑删除此类 getter 和 setter。
话虽如此，如果您需要向用户显示某些内容，那么这是其他对象需要了解的属性。 出于多种原因，对象不应该关心如何显示自身。 其中之一是，如果不知道应用程序如何使用它，它就无法知道应该如何呈现它，这将使 IT 对其他对象了解太多。
The point of encapsulation is hiding implementation. There is "state" that other objects do need to know about -- sometimes the whole purpose of an object is telling such state.
For instance, it would be pretty useless to have a Defined Finite Automata object which doesn't have a getter for whether it's on a final state or not. But it's certainly useful to encapsulate how that information is stored internally.
Now, the goal of getters and setters is to provide an interface to properties of a state of an object, which might not have anything to do with how it is actually implemented. Granted, most of the time these properties are fields in the object, and the getters and setters just shallow shells. On the other hand, you have the freedom to change the internal implementation, because the getters and setters will ensure interface compatibility.
If, however, these properties are too related to the actual implementation and not so much with what the object is about, then you should consider removing such getters and setters.
Having said all that, if you need to display something to the user, then this is a property other objects need to know about. An object shouldn't be concerned with how to display itself, for many reasons. One of them is that it can't know how it should be rendered without knowing how it is used by the application, which would make IT know too much about the other objects.