[Exceptional C++ Style] Item 14: Order, Order!

[SamS at helpIT.com]

>>>>> In that case it is a definition that you should make
>>>>> explicit, because the definition of strength is otherwise
>>>>> unqualified and people will fall back on the associations
>>>>> normally used when describing relationship strength and
>>>>> thoughts of coupling, cohesion and dependency management in
>>>>> general. However, even after clarifying the terminology,
>>>>> friendship still ranks second: membership is a stronger binding.
>>>>
>>>> Why?  A member does not depend on the class containing it.
>>>
>>> Err, yes it does: that is fundamental to the definition of
>>> membership!
>>>
>> It looks like Kevlin is speaking about member _functions_ and WW
>> about member _data_. It is obvious to me that function membership
>> provides the strongest binding, but, in C++, data membership surely
>> has a weaker binding than both friendship and inheritance?
>
> In this context I would not expect to be talking about data members as
> it wouldn't make as much sense -- it would not be the same or a
> related topic of discussion. As we started talking about friendship,
> the notion was the dependency that a piece of executable code could
> have on a class. Hence the concern about relationship strength and
> breadth. Friendship can be granted to types and functions, and it is
> these that would be granted access privileges. The related member
> concept is member functions and nested classes, not data members.
>
I beg to differ; it does make sense to talk about data membership in this
context as we were talking about friendship vs membership vs inheritance.
Inheritance and containment/membership are two types of class relationships,
where the inheritance relationship results in stronger binding then the
containment relationship. So, from my perspective there was plenty of room
for misunderstanding what type of membership we were speaking about.

> That said, there is of course some kind of dependency of data members
> on the surrounding class -- initial value, permissible access, etc --
> but, interesting as that is, it is not really what we are discussing.

As you say, interesting as this is, it is not really what we are discussing.

Sam