Re: Class::SelfMethods

I don't want to sound like a spoil sport, but recently Allen Holub has written a rather interesting article for JavaWorld with the provoking title "Why getter and setter methods are evil".

In the article he cites a variety of reasons why to avoid getters/setters and maintains that an abundance of such methods is a sure sign of poor OO design. It's definitely worth the read.

Just my 2 cents, -gjb-

Comment on Re: Class::SelfMethods

Replies are listed 'Best First'.
Re: Re: Class::SelfMethods by John M. Dlugosz (Monsignor) on Sep 15, 2003 at 23:50 UTC
Thanks for the reference. I have a beef against getters/setters myself, but from the point of view that automatically generating get/set methods to match all the data fields is missing the point. Holub is against obtaining information from an object in general, summed up by his description from the CRC methodology: You may not ask for the information you need to do something. Rather, you must ask the collaborator who has the information to do the work. It's okay to pass to that collaborator information he needs to do the work, but keep this interaction to a minimum. I intuit that to some extent. In my OO design, if code asks X for a bunch of stuff and then does something, then that something really should have been a member of X. I don't follow what he said about how he puts the drawYourself member in the class but really implements it someplace else. Hmm, maybe I do: user of the object calls drawYourself, but it just turns around and calls a function in the UI layer, passing it the relevant information (not the whole object). I see, that's an example of "send it out but don't ask for it". I don't see how that fits his thesis about being able to change the types involved. Which ever class really implements the code (assuming it's implemented in only one place) still needs to change. All the code it calls out to, passing the information needed, needs to have their parameters changed. How is that different from changing the types of variables where information is asked for? --John	[reply]

Replies are listed 'Best First'.

Re: Re: Class::SelfMethods
by John M. Dlugosz (Monsignor) on Sep 15, 2003 at 23:50 UTC

I have a beef against getters/setters myself, but from the point of view that automatically generating get/set methods to match all the data fields is missing the point. Holub is against obtaining information from an object in general, summed up by his description from the CRC methodology:

You may not ask for the information you need to do something. Rather, you must ask the collaborator who has the information to do the work. It's okay to pass to that collaborator information he needs to do the work, but keep this interaction to a minimum.

I don't follow what he said about how he puts the drawYourself member in the class but really implements it someplace else. Hmm, maybe I do: user of the object calls drawYourself, but it just turns around and calls a function in the UI layer, passing it the relevant information (not the whole object). I see, that's an example of "send it out but don't ask for it".

I don't see how that fits his thesis about being able to change the types involved. Which ever class really implements the code (assuming it's implemented in only one place) still needs to change. All the code it calls out to, passing the information needed, needs to have their parameters changed. How is that different from changing the types of variables where information is asked for?

--John

[reply]