[Exceptional C++ Style] Fw: const data - was Item 17

[Terje Slettebø]

>From: "Kevlin Henney" <kevlin at curbralan.com>

> In message <011201c4e79c$4f081260$0300000a at pc>, Terje Slettebø
> <terjesl at broadpark.no> writes
> >
> >> In general, we have multiple strong forces fighting each other.
> >> One is encapsulation -- thoroughly analysed in item text. That would
force
> >> us to maximal hiding, minimise coupling and dependencies.
> >> The other forces are coming from XP experience -- to keep things the
> >> simplest
> >
> >I don't think there need to be a conflict, here. By keeping things
private,
> >unless they need to be public, we make the simplest (public) interface
that
> >could possibly work. ;)
>
> The problem here is the definition of the word "simple", which is a
> highly subjective one. Many people who try XP assume "simple" means
> "simplistic", which is altogether a different thing.

Absolutely. I think this is somewhat addressed by the quote "Make it as
simple as possible, but no simpler." A simplistic "solution" tends to gloss
over important aspects, and hence doesn't really solve the problem (in a
good way).

> Making data public
> is simplistic because it a short-term convenience, a shortcut, with the
> affordances in the resulting code are definitely non-simple.

Which was my point: Having a simple (public) interface, i.e. only make
public what makes sense to be public.

> Anyone can
> set any member to any value, which is rarely the right thing, and
> changing representation would break tests and production code. It is in
> fact the XP experience that suggests that making data private is the
> simpler of the two options because it enables refactoring and late
> changes in representation with minimum breakage.

Yeah, and so far your posting is in agreement with mine, as well as adding
the point about simple/simplistic. I had the impression that it was meant to
contrast my posting (starting with "The problem..."), but perhaps not.

> >>, and solve the problems we have instead of going to premature
> >> generalisations or solving the problems possible for the next century.
> >
> >Generalisation is rather orthogonal to encapsulation, I think.
>
> Except when it isn't ;-)

Could you elaborate?

Regards,

Terje