Re: iterator ranges; eliminating private member functions

From: williamkempf_at_[hidden]
Date: 2001-11-01 17:55:17

--- In boost_at_y..., "Kevin S. Van Horn" <kevin.vanhorn_at_n...> wrote:
> On Wed, 31 Oct 2001 williamkempf_at_h... wrote:
> 
> > > [My description of "minimal but complete" class interfaces.]
> > There's a reason to prefer (3) in a general sense.  I forget the 
OO
> > principles name, but in essence the public interface should
> > be "minimal but complete".  This principle can be taken too far,
> > however.
> 
> Would you care to elaborate?  What do you consider taking it too 
far, and what
> criteria do you propose for when one should violate the principle?
> 
> > > [I discussed the problem with (1): Once a member function, 
always a
> > > member function, even if in a later implementation the function 
doesn't
> >   need access to the class internals.]
> >
> > [...]  I see nothing wrong with
> > the function remaining a member function,
> 
> It's called *encapsulation*, something that OO enthusiasts claim to 
be in
> favor of.

Actually, that's a perversion of the term you're using.  Yes, there's 
an OO principle that tells you to decouple dependencies when ever 
possible, and this leads directly to the "minimal but complete" 
principle.  But lumping these principles under the guise 
of "encapsulation" is awfully misleading.

>  Let me start from the beginning again, since I don't seem to be
> communicating my point well.  If you disagree with my analysis, 
please make
> clear the specific point or points you disagree with and why.
> 
> 1. You make your code easier to maintain and more reliable by 
decoupling
> different pieces of code as much as possible.  That is, you want the
> correctness of code piece A to depend as little as possible on the 
details of
> code piece B, and vice versa.  This allows you to localize 
modifications to
> the code.  As someone who's spent many a tedious hour grepping 
through source
> code to make one small change to an ill-encapsulated code base 
inherited from
> others, I am a big, *big*, BIG fan of encapsulation.

Other than my disagreement with your usage of the term encapsulation 
we're in agreement on this one.
 
> 2. One important technique for decoupling different pieces of code 
is to not
> allow any function to have access to the innards of a class unless 
it really
> needs access.  Letting it have access means that you have to review 
the
> function definition when changing the class implementation; 
furthermore,
> functions that have access to a class's innards tend to become 
reliant on
> implementation details of the class, and require updating 
themselves when the
> class implementation changes.

And again I agree with your principles.  However, I think you and I 
disagree at least somewhat on when methods really need access to 
implementation details of the class.  This is just a feeling from the 
discussion, but I believe you and I disagree about when performance 
concerns constitute a need here.
 
> 3. There are two kinds of functions that have access to the innards 
of a C++
> class: member functions and friend functions.  Thus, a function 
should not be
> a member or friend function unless it really needs access to class
> implementation details.

You're starting to go down the wrong road here by mentioning 
friends.  I know this only because of previous discussions on this 
topic, but your use here is screaming at me.
 
> 4. If the implementation of a class changes and a friend function 
no longer
> requires access to the class innards (you can efficiently implement 
it on top
> of other operations), it is easy to deny the function access to the 
class
> innards -- just remove the friend declaration.  This does not 
change the user
> interface and does not break any existing code that uses the class.

This just causes maintenance problems.  You could easily find 
yourself switching back and forth between friend and non-friend 
implementations.  However, if you take the approach I've suggested 
instead this is a non-issue.  You make your best guess as to whether 
a method should be free standing or a member, and if you find you 
made the wrong choice in the future you simply add the version that's 
missing and your maintenance woes are finished with out breaking any 
client code.
 
> 5. If the implementation of a class changes and a member function 
no longer
> requires access to the class innards (same reasons), you are now 
forced to
> break encapsulation principle (2).  You cannot change the member 
function into
> a non-member function, as this changes the syntax by which it is 
called and
> would break existing code using the class.  The member function 
must remain a
> member function, which means that you have to give it access to the 
class
> innards even though it doesn't need this access.  Your design is 
now less
> encapsulated than it should be.
> 
> > > Once a function is declared as a member function, there's 
nothing you
> > > can do to stop library users from writing x.some_operation() 
instead of
> > > some_operation(x), and hence you cannot later make 
some_operation()
> > > a non-member without breaking existing client code.
> >
> > 1)  Why should you prevent them from writing x.some_operation()?
> 
> As described in point 5 above, any such use forces some_operation 
to remain a
> member function, which means that it will forevermore have access 
to class
> implementation details, even if it doesn't need them, resulting in 
an
> encapsulation violation.

Ahh, so that's how your perverting encapsulation.  You're taking it 
to mean that if a method doesn't need access to implementation 
details it simply shouldn't be given access.  But that isn't the 
purpose of encapsulation.  The purpose of encapsulation is to *hide* 
the implementation details.  You don't know, nor should you care, if 
x.some_operation() requires access to internal details of the class.  
This allows the class implementer to change the implementation, which 
may change whether or not x.some_operation() needs access, with out 
any impact to client code and with minimal impact to maintenance.

So, these are the rules I live by.

1)  If you need a method requires access to implementation details of 
the class make it a member.
2)  If you know that a method could be more efficient if it had 
access to implementation details of the class make it a member.
3)  If you are uncertain if a method will be more efficient if it has 
access to implementation details of the class make it a non-member.
4)  If you later find that a non-member could be more efficient if it 
had access to implementation details of the class add a member and 
have the non-member call it.
5)  If you find you need a free function in order to work with a 
generic algorithm you simply create the adapter.
6)  You always avoid friends unless there's no other efficient 
solution as they are a kludge to work around encapsulation which lead 
to code that's hard to maintain (this is especially true for friend 
classes).

> > Generic algorithms have a choice for supporting either syntax, and
> > often it will be appropriate for them to use the x.some_operation
()
> > syntax.
> 
> The code of the generic algorithm itself should not use the 
x.some_operation()
> syntax, as this limits the algorithm to only be applicable to data 
types which
> are classes providing some_operation() as a member function, and 
rules out the
> possibility of adapting other types for use with the algorithm.

This is simply wrong.

template <typename T>
void call_foo(T o, bar b)
{
   o.foo(b);
}
void foo(bar b);
class foo_adapter
{
public:
   void foo(bar b) { ::foo(b); }
};
call_foo(foo_adapter(), bar());

Adapters freely allow you to change the interface in any way you need 
to.

> > This means that I find it flatly
> > wrong to avoid member functions simply because there might, maybe,
> > someday, be a generic algorithm which is going to use a free 
standing
> > method instead.
> 
> That's not my reason for avoiding member functions, although it can 
be a
> reason for wanting at least a non-member wrapper function.  Points 
1-5 above
> are my reason for avoiding member functions.  Even if you don't 
think 4 and 5
> happen often enough to be important, points 1-3 (a distillation of 
Scott
> Meyers' arguments) are still a strong argument for avoiding member 
functions
> when you don't need access to the implementation details of a class.

Again, I don't have problems with free standing functions, but *only 
when they do not need access to class internals*.  What I disagree 
with, very strongly, is your choice to use friend functions instead 
of member functions.  The only reason for such a choice is to allow 
for usage with generic algorithms.  That's a poor defense for 
weakening encapsulation (which is what friend does).

> > 3) Free functions don't clearly indicate the coupling to the 
object.
> 
> And just what does "coupling to the object" mean?  The fact that 
the object is
> being modified?  Not all member functions modify the object.

As you yourself pointed out, it's the maintenance coupling that 
matters the most.  If you change the implementation of a class you 
need to know which functions this can impact.
 
> > If it were purely syntax you'd have more of an argument, but it's
> > not.  In any event, I prefer the x.some_procedure() syntax any 
way,
> > so I'd argue that if you want uniformity we should make everything
> > follow this syntax ;).
> 
> No, uniformity would argue against using x.some_procedure() for all 
functions,
> as it treats the first argument (x) differently from the others, 
even when the
> arguments are symmetrical.  Java's clumsy a.eq(b) (as opposed to a 
= b or
> a == b) is an example.

Bertrand Meyers takes strong exception to this in OOSC2, and his 
arguments are well reasoned and were considered *before* the syntax 
was chosen for Eiffel.  So at best you're entering into a religious 
war here.
 
> > So I find it to simply be wrong to
> > program the interface assuming a generic usage.  It makes the 
design
> > more fragile [...]
> >
> > 1) Friends are fragile and are open to abuse.
> 
> Explain to me how use of friends makes the design fragile.  Explain 
to me how
> friends are *more* open to abuse than member functions, as both 
must be
> declared in the class declaration.

Fragile because many compilers have problems implementing them and 
because the violation of encapsulation causes maintainance problems.  
I probably spoke too quickly when I mentioned being open to abuse 
because most of the flaws here apply to friend classes and not friend 
functions.
 
> > 2) Free functions pollute the namespace.
> 
> That's why we have overloading.  There may be some implications in 
the
> interaction of member functions vs. non-member functions in C++ 
overload
> resolution that would result in ambiguities for the latter but not 
for the
> former.  This would be a valid argument in favor of the member 
functions, and
> my uncertainties on this point are the one reason I am still only 
considering
> the friend-over-member approach.  If you have specific examples of 
where the
> non-member syntax would cause problems but the member syntax does 
not, I would
> like to see them.

Overloading does not and can not replace namespace protection 
(whether through the namespace keyword or through the more generic 
usage of this term that applies to class members).  Overloads still 
pollute the namespace they are declared in and can easily lead to 
ambiguities in numerous ways.

Bill Kempf