Quote:
Of course, a drawYourself() strategy means that I (gasp!) put UI code into the business logic. Consider what happens when the UI's requirements change. Let's say I want to represent the attribute in a completely different way. Today an "identity" is a name; tomorrow it's a name and ID number; the day after that it's a name, ID number, and picture. I limit the scope of these changes to one place in the code. If I have a give-me-a-JComponent-that-represents-your-identity class, then I've isolated the way identities are represented from the rest of the system.
I have some issues about this GUI-part.
You make believe that the changes to the GUI are very small and concentrated in one method.
Isn't one of the greatest advantages of the MVC-model the clean seperation of the different functions, thus enabling to port the same business-logic to different UI's, and not just maintaining the UI.
What happens when for instance I want the object to be painted on several different types of terminals??
I have for instance a text-only terminal which should be able to give me textual output of the environment, I also have a full graphical interface, I would also like to have a web-interface (full html) a wap-interface and some other mobile-phone interface (some other kind of XML).
Or what if my business logic consists of graph-representation and I would like to have a pictural overview of the graph on which I can change the representation of every single node or edge of the graph (not changing the business-model objects).
You could utter that an object that takes care of the representation or perhaps a link to a GUI-factory can be embedded in the object (this is much like using a method to draw the object, here using the method of a drawing-object), but that makes the GUI-code and memory usage always necessary. When I would like to make a lightweight and fast calculating-server using the business-model, I don't want the GUI-capabilities to be part of the memory- or even CPU-usage.
I agree on the evilness of setters (thus using immutable objects as often as possible),
but I think the getter-part is exagerated.
I would suggest to use the more moderate approach,
only implementing those methods in the class when they are really necessary, and making sure that construction can only create correct objects. (if you should use construction after all (also considered evil))
Your point about changing the interface of an accessor from returning an int to returning a long:
When will this change occur??
When it occurs during implementation, it can have two causes:
- the implementor thinks longs are better for internal details of the class --> this should not reflect in the getter-signature.
- the implementor thinks the overall behaviour is not right working with ints and exceptions are waiting around the corner working with ints. --> this will affect every other referencing class anyway.
When it occurs after the development:
- then these accessors can be seen as a part of the contract/interface and changing them should happen according to specific rules. This almost always involves keeping the old setters/getters for a while as being deprecated and ...
What I want to say with the previous section is:
--> what problems do occur so frequently with getters that do not occur with other methods. I think changing from int to long will probably have something to do with doubling the precision and thus affecting all of the code, and if not, the getter can still be returning ints after the change.
For your remark on the ease of removing 99 percent of all accessors, I really think you exagerated.
Taking away 99 out of 100 accessors would render only one accessor (setter or getter) in possibly over 10 classes (50 fields).
I just can't believe that anyone could even make a program doing something useful containing so little accessors. I would have liked an example.
I think everyone should beware of creating unneccesary methods whether this are getters, setters or other methods.
I also think everyone should make these methods as hidden as possible (by using private over package-visibility over protected over public).
But no one should eradicate all of the accesssors in favor of good OO.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
