Re: Holub on getters/setters again
From: Daniel Parker (danielaparker_at_spam?nothanks.windupbird.com)
Date: 01/23/04
- Next message: Daniel Parker: "Re: Holub on getters/setters again"
- Previous message: Andrew Thompson: "Re: Mars Rover Not Responding"
- In reply to: Daniel T.: "Re: Holub on getters/setters again"
- Next in thread: Daniel T.: "Re: Holub on getters/setters again"
- Reply: Daniel T.: "Re: Holub on getters/setters again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 22 Jan 2004 23:46:14 -0500
"Daniel T." <postmaster@eathlink.net> wrote in message
news:postmaster-D4ECDB.22313422012004@news03.east.earthlink.net...
> brangdon@cix.co.uk (Dave Harris) wrote:
>
> > danielaparker@hotmail.com (Daniel Parker) wrote (abridged):
> > > Now, I submit that nearly everybody on this newsgroup
> > > would have an answer to the question, "Is this method a getter?"
> > > Nearly everybody, but not Ron. Ron would say, "No, we can't tell, we
> > > have to look at the source first."
> >
> > :-) I can make the situation worse by adding history into the mix. If we
> > start by defining the class interface and then later decide which
> > accessors are backed directly by instance variables, that's good. If
> > instead we start by implementing the class with its variables, and then
> > add accessors for every instance variable without considering whether
any
> > client needs them, that's bad.
>
> I'm not so sure that the latter approach is "bad". I mean one ends up
> doing work that may not be used, and that is bad, but in the case of a
> class that will be published to the whole world, it behoves the designer
> of the class to provide to clients as much information about the
> object's state as possible. One never knows, in these situations what
> the client might need.
>
I think I'm with Dave Harris on this one, my instincts would be to expose as
little as possible until there was a demonstrated need from the client. I
would also be extremely reluctant to add setters unless they fitted in
naturally to the overall design of the class, e.g. Holub's Exporter classes,
or a factory class. The more you expose and commit to supporting, the less
opportunity you will have for changing the implementation in the future.
Regards,
Daniel Parker
- Next message: Daniel Parker: "Re: Holub on getters/setters again"
- Previous message: Andrew Thompson: "Re: Mars Rover Not Responding"
- In reply to: Daniel T.: "Re: Holub on getters/setters again"
- Next in thread: Daniel T.: "Re: Holub on getters/setters again"
- Reply: Daniel T.: "Re: Holub on getters/setters again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|