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
In reply to Re: Re: Class::SelfMethods
by John M. Dlugosz
in thread Class::SelfMethods
by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |