Re: Holub on getters/setters again
From: Daniel T. (postmaster_at_eathlink.net)
Date: 02/03/04
- Next message: Brian S. Smith: "Re: Class Diagrams as Requirements or Design?"
- Previous message: Brian S. Smith: "Re: Class Diagrams as Requirements or Design?"
- In reply to: Ilja Preuß: "Re: Holub on getters/setters again"
- Next in thread: Ilja Preuß: "Re: Holub on getters/setters again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 03 Feb 2004 01:58:18 GMT
"Ilja Preuß" <preuss@disy.net> wrote:
> Daniel T. wrote:
> > Assuming that is the case, I don't care if all
> > the methods are accessors, and I don't see how an interface of this
> > sort could limit the server any more than is necessary to provide for
> > the client's need.
>
> Let's assume that setting a new high value is costly in our system. Let's
> also assume that we could optimize the implementation by not setting the
> high value, but remembering the max value instead. With the pure
> getter/setter interface, you simply can't implement that solution, so it
> seems to me.
>
> Does that compute?
Are you saying that I couldn't convert setHigh/getHigh into
non-accessors? I don't see why that would be the case. As we have
already discussed, for all you know, they aren't anyway (because our
range class was a pure interface with no implementation.)
> >>> In any case, we aren't
> >>> talking about "the design" as a whole, we are talking about wether a
> >>> particular method is appropriate or not.
> >>
> >> And that seems to be the problem of this discussion: I *was* talking
> >> about the former, and I understood Ron to talk about it, too. That's
> >> what "accessors are code smells" means: they are a hint to the fact
> >> that there might be something inappropriate with the design as a
> >> whole.
> >
> > Humm... The assumption seems to be that accessors are a hint because
> > there is something inherently wrong with some of them.
>
> No. The assumption is that there is something potentially wrong with using
> them too much.
With *using* them... Wouldn't it then be better to focus on the client
code and how it uses the server methods, rather than focusing on how the
server happens to implement those methods?
> >> In fact, I don't think that you can tell wether a method is
> >> appropriate without taking a look at how it gets used. (You might be
> >> able to tell wether it is *implemented* appropriately, but not
> >> wether its *existence* is appropriate.)
> >
> > I will agree with this completely, however how a method is used has
> > *nothing* to do with how it is implemented.
>
> Mhh, I have to think about this...
Yes, please do. It is my strongest argument yet.
> >> Well, we hopefully were. I typically also learn something while
> >> designing and implementing a system, and prefer to put that learning
> >> into the system, too. Taking a look at how accessors get used is one
> >> effective way to learn interesting things about the design, for me.
> >
> > How are "accessors" different from other methods in this regard?
>
> They are a hint that clients may be more interested in data than in
> behaviour. Especially they might hint to clients implementing operations on
> the data which would better be placed closer to the data. Therefore they can
> be quite specific hints to quite specific design problems.
>
> >> Without further information I would say that putting the method into
> >> the Range class provides better encapsulation and therefore it
> >> should be preferred.
> >
> > Actually, according to Scott Meyers, the primary proponent of the
> > "community" being discussed, it provides worse encapsulation. By
> > adding
> > yet another method to the range class, you are increasing the amount
> > of
> > code that must be examined if the implementation of the class changes.
>
> I disagree. The code is coupled to the data by accessing it, independent of
> where it resides. By putting it on the class we just make the coupling more
> explicite and there reduce the number of places you have to look at for
> possible side effects.
>
> > By putting this "trimRangeHeighTo" outside of the range class, I can
> > change the implementation of the class without having to worry about
> > breaking the "trimRangeHeighTo" method/function.
>
> Do you? How does putting it on a different class protect it from breaking?
Because it allows one to change the implementation of the class without
examining the implementation of trimRangeHeighTo (assuming it isn't in
the class.)
> > There is something of a trade off here I'm sure.
>
> Yes, I wholeheartedly agree. As I said (I hope), I could imagine not putting
> the method directly on the Range class.
>
> > The
> > more
> > code in the class, the more freedom it has to modify its
> > implementation without affecting clients,
>
> Yes!
>
> > but it also means there is more code that
> > must be examined when a change is made...
>
> I am not sure that this is inherently true (see above). But there are
> probably ways to further decouple the trim method from the Range class...?
I think it is inherently true, every time you change the implementation
of one method of a class, you must at least examine all the other
methods to insure that they haven't been broken by the change. If you
don't, then I would say you don't have a clear separation of concerns.
This doesn't count for client methods though, they are the ones that
drive the servers interface, which is what forces the server to a
particular implementation.
Let me present a concrete example. The C++ std::string class has some
120 different methods. That's quite a parcel for a class that implements
a very single minded and basic concept. Yet, there is no method for
trimming whitespace off the ends of strings (something that I have used
quite often.) Does that mean I should push to have the method included
in the class? Is the class deficient because this method is missing? Of
course not, I'm able to implement my own trimWhiteSpace function using
the public interface available, and what is more, if the implementation
of std::string changes, I don't have to worry, because I'm relying on
the (much more stable) public interface to implement my function. If I
were to implement trimWhiteSpace as a string method, then it stands to
reason that I would have to at least examine it's implementation
whenever I modify the implementation of string (for example if I switch
to COW semantics.)
Now, it may be that calling my trimWhiteSpace is much more costly in
time than if it were implemented using special knowledge that only a
member-function (method) has access to, put putting the method in the
acutal class gives us just one more method we have to fix if we need to
re-implement std::string as a deque (ie a series of discontigious blocks
of memory.)
Some of the methods in std::string seem to force it into a particular
implementation. For example the method 'c_str' and 'data' return a
single contiguous piece of memory (a C style array) that contains the
entire contents of the string. This implies that the class actually
contains the entire contents as a single contiguous block of memory, but
that doesn't have to be the case. I could easily present the exact same
interface (ie have a 'c_str' method) with a completely different
implementation. Calling this method would then be much more expensive
however because the class would have to allocate the block a memory and
set the values of each byte (and then, because we are talking about C++,
it would have to track that allocation and delete it when appropriate.)
Despite the fact that 'c_str' tends to force the implementation, it is
still a completely appropriate method to have in a string class designed
for C++. Clients *need* this getter, even if it isn't implemented as
such.
I'm becoming long winded because my family is out for a stroll and I'm
home alone, I better stop. :-)
- Next message: Brian S. Smith: "Re: Class Diagrams as Requirements or Design?"
- Previous message: Brian S. Smith: "Re: Class Diagrams as Requirements or Design?"
- In reply to: Ilja Preuß: "Re: Holub on getters/setters again"
- Next in thread: Ilja Preuß: "Re: Holub on getters/setters again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
