[Exceptional C++ Style] Item 17 - Encapsulation

[Jon Jagger]

solosnake . wrote:

>> From: Jon Jagger <jon at jaggersoft.com>
>
> *snip*

more snipping

>>
>> Don't get me wrong now. I'm all for encapsulation. For example, 
>> size() is a method on the STL containers and that's right and proper. 
>> No one is suggesting that size should be a public (non-const) data 
>> member. Encapsulation is a principle which if sensibly applied brings 
>> tremendous benefits. But if misapplied it can bring more harm than good.
>
>
> I don't think you are being fair here - the original question was 
> whether public const member data was acceptable. I say it is not, and 
> provided a simple example of how even the thinnest of wrappers 
> provided a degree of usefulness and minimised dependencies on class 
> internals. I was not attempting to provide an example of an actual 
> real world class (hence names like 'SomeData' and Case1).

In a sense you are right because the original question is a trap. The 
best answer to the question "is public const member data acceptable?" is 
mu. That is, answering either yes or no does not really get anyone 
anywhere. So let's blame Paul (after all, everyone else does ;-) You say 
your answer is "no" and I say my answer is "it depends" - that there is 
almost never a blanket rule that applies 100% of the time. And if 
someone claims to have one you should be wary. I provided one somewhat 
unusual example where, in my opinion, the balance of forces tips towards 
public const data.

In other words I'm in agreement with Balog Pal when he writes....

<quote>
Right interface can't be summoned on general terms, and spoke about without
a well-established context.   The shape and amount of both public data and
functions must be considered with the task, purpose of the stuff we are
creating.
</quote>

It pays to look at the problem - the specific problem - before deciding 
upon a solution. Unless you have a "real" problem you are not doing real 
design - and your liable to get lost in an endless maze of choices.

>
> To bring this back to the original point - should classes be allowed 
> expose member data if that data is const? I still say no. 

And I still say "it depends". Without seeing the actual concrete context 
how can we tell?

> The function of the class should be made apparent via its interface, 
> and even if all a class did was provide access to some const data, it 
> is still advantageous to wrap this in an interface. If there was just 
> a single reason to do this, surely that is all it should take to 
> convince you? 

Absolutely. Yes. And in the majority of cases I'm sure we'd be in 
perfect agreement - that this problem or that problem had (often many) 
very good reasons. All I'm saying is that in my specific case I couldn't 
find even one good reason.

> And there are several:
>
> 1) The user of the class depends on the class member functions, which 
> guarantee certain behaviours, but allow the implementor freedom of 
> internal design.
> 2) It allows the use of compiler firewalls etc (if data is returned 
> via pointer/reference).
> 3) It allows the member data to be non-const even if the class user 
> sees only a const version.
> 4) The class can be safely changed (to some degree within the design 
> parameters) without changing the code that uses it (this is a variant 
> on #1 really).

But none of these apply in my case. Bending the design of what I know I 
need to accomodate hypothetical features I cannot imagine wanting or 
needing (after many months of intimate experience) does not seem a good 
idea. Design is not about providing the maximum number of features and 
"flexibility" (whatever that means) - it's about providing the _minimum_ 
number of features. Constraints do not limit design they provoke it.

Cheers
Jon