Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 20, 7:33 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Noah Roberts:
Alf P. Steinbach wrote:
* Noah Roberts:
and there's the other case when you don't care but
sometime down the road someone decides that a subclass
should be returned rather than the one you're
constructing.
You don't. That's totally evil. You're *changing the
behavior* without changing the type, leaving client code
stranded with mysterious behavior change.
That's only true if one of two things is true:
* Your client code is depending on the private behavior of
the class instead of the advertised pre/post conditions.
* Your new sub object violates the advertized pre/post
conditions of the class it inherits from.
If the new class changes nothing wrt. client code, then there
is absolutely no reason to foist a replacement on the client
code.
Huh? The behavior can easily depend on various elements in the
external environment. Under X, for example, it is frequent to
support several look and feels, determined from an environment
variable, a configuration file or whatever. The immediate
client of the code doesn't know or care about the look and feel,
it wants a button. So your factory function returns a button
with the correct look and feel.
For that matter, I use a similar strategy for handling
differences between Windows and Unix: for reading directories,
for example, if I'm under Unix, the necessary data is a DIR*,
under Windows, a WIN32_FIND_DATA, but neither appears in the
class definition the client sees.
I thought you'd understand that from my comments, but I wasn't
clear enough.
So let me put it this way: *either* the new class is different
in some way that affects behavior, in which case you're
changing the behavior, or else it's not, in which case it's
not very smart to do a lot of work to replace the original.
You seem to be missing the difference between contractual
behavior, and implementation behavior. Roughly speaking: what
(the class does) and how (it does it). The contractual behavior
(the "interface") is just that, contractual. But you often have
need for different implementation behavior.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34