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

[Kevlin Henney]

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

Contrary to popular opinion -- and a point I have made before -- 
encapsulation is not about making data private. It is about introducing 
a boundary in order to simplify usage, preserve constraints and keep 
degrees of freedom open. Data privacy is one natural consequence of this 
approach, but there are others.

Going back to the original issue, trying to determine whether or not 
public const data is encapsulated or not is an attempt to impose binary, 
yes-no judgement on a quality that is clearly continuous in nature.

For example, is a class with setters and getters in a one-to-one mapping 
with private data encapsulated or not? It is certainly the case that it 
is not particularly well encapsulated, but it is certainly more 
encapsulated than the corresponding struct with just public data: the 
usage can constrained to affect data in only particular ways, eg range 
enforcement, and the representation can be changed by adding a level of 
indirection, eg a handle-body structure. Of course, the number of 
degrees of freedom that are left open is fewer than with a more 
usage-centric interface, but there is more freedom than with a 
public-data struct. Usage could be simplified by a more intentional and 
service-oriented interface, and there is little difference between such 
usage and the usage of a public-data struct. Some constraints are not as 
easily preserved as they might be with a more usage-centric interface, 
but they are more easily preserved than with a struct interface.

So, back to immutable data. Public immutable data is more encapsulated 
than public mutable data because it eliminates a large class of 
incorrect usages, ie it has few unintended and malign affordances. It 
may or may not simplify usage, but that depends on the specific 
situation. The one Jon has presented it seems not to cause any problems. 
However, the degrees of freedom open to the implementor are restricted, 
eg should Jon wish to switch to a handle-body representation he cannot. 
So, yes, public immutable data is more encapsulated than public mutable 
data, but it is still not as encapsulated as private data.

>>, 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 ;-)

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________