Re: std::string bad design????
"Le Chaud Lapin" <jaibuduvin@gmail.com> wrote:
Daniel T. wrote:
located element:
phonebook.locate("Le Chaud Lapin");
phonebook.RHE() = "08 70 35 19 38";
Others have objected to the above based on threading issues, I'm not
sure that is relevant since C++ doesn't have any standard threading
model, but I have a different objection.
Your phonebook object has internal state that the user of the object
must know in order to use it correctly. In other words, I can't call
RHE() without first checking, or otherwise knowing, that the internal
marker is in the right place. I call that poor encapsulation.
As it turns out, the only context in which RHE() would be called is
when it is known in advance that the internal marker is in the right
place. In my years of using these containers, I have never encountered
a situation where this was not true. This is intuitive - one could
simply ask the question, "Why, at this particular point in the code,
are you calling RHE()?" and the answer will always reveal that the
position of the marker is unequivocally known just prior to calling
RHE().
Exactly. Thank you for agreeing with me. The position of the *internal*
marker must be unequivocally known prior to calling RHE(), this means
that either all calls to RHE must be immediately preceded by a call to
locate() or the programmer writing the client code must somehow know
that the *internal* marker is in the right position.
If you are expecting your clients to do the former, then you should
provide a single method that does both steps for them. If you are
expecting them to do the latter, then you obviously have poor
encapsulation. You are requiring clients of the class to keep track of
the object's internal state.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]