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?
A:
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.
chaos
2009-07-26 14:27:22
The question is not about saving work. In everything there are tradeoffs. My believe is that there is a always going to be a tradeoff between a RAD framework, and well designed system. The RAD framework will never produce good maintainable code, but it gets the job done quick. I'm just trying to solve a problem in a "pure" fashion, by trying to stick to OO principles as much as possible, because I believe that's the best way to make a maintainable system
blockhead
2009-07-26 14:45:31
The reason to make something a maintainable system is to save work in maintenance. If you let "purity" get away from its motivation in "saving work", you will wind up with a wonderfully "pure" system that's horrible to work with. It happens all the time.
chaos
2009-07-26 14:50:28
A:
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.
Daniel
2009-07-26 14:38:28
As far as that last point, the interface will take care of how it's being rendered. The object won't know any more than that its giving over some of its state to a "renderer", but doesn't know what the render is doing with it. The real question is, is that considered too much coupling (maybe the object should not even know that it needs to be rendered), or am I just nuts.
blockhead
2009-07-26 14:42:22