[Exceptional C++ Style] Item 17 - Encapsulation

[solosnake .]

>From: "Paul Grenyer" <paul at paulgrenyer.co.uk>

*snip*

>There's another issue I've been wanting to discuss for a while and now 
>seems
>the appropriate time.
>
>At the ACCU conference before last (2003) I was in a presentation being
>given by Jon Jagger on a parser he had written. He had some public data in
>one of his classes and when I queried him on it he said it was const (which
>it was) and therefore it didn't matter if it was public.
>
>I have never been able to make my mind-up whether I agreed or not. What do
>people here think?
>
>The immediate reason why not that comes to mind is that which is discussed
>in the item about not being able to modify the class to do something like
>count the number of times the data is accessed without changing the
>interface. So, my thinking is that even constant data shouldn't be public.
>
>I imagine (and correct me if I'm wrong) that this item is unlikely to cause
>much controversy and that constant public data might provide a good
>discussion.
>
>Regards
>Paul
>
>Paul Grenyer

I doubt item 17 will prove controversial, but agreeing that public data 
members when const are ok will I think :) I am against them (although do 
what I say, not what I do please!). True, they may be non-modifiable, but 
they still cause a data dependancy, and given that there is no strong reason 
why they are more useful being public then accessed via member functions, I 
think they are not a good idea. Other reasons not to is that it can break 
the consistency of the code style: it's harder to argue for encapsulation if 
you allow these special cases. You also require that data member to remain 
const in the future.

Cheers,

Daire Stockdale