[openbeosstorage] Friendship vs. Protection

> > >   Personally I vote for reducing those dependencies where possible, i.e.
> > >   to make stuff needed by subclasses protected and to analyze whether
> > >   friendships to other classes are really needed.
> > 
> > I'm going to reservedly say yes, I think this would probably be a better
> > way of doing things. The one thing that sticks out in my mind as
> > something we'll gain is the ability for the person writing a given class
> > to be responsible for checking initialization status and parameter
> > validity before using private data members. Certainly the person writing
> > the friend class could do this as well, but it's more likely to be on
> > the mind of the person writing the class that's being manhandled. Plus
> > that way you write it once for each accessor as opposed to every time
> > you access a private data member in a friend class. Being able to
> > subclass the Storage Kit classes more easily is a bonus as well, but I
> > don't know that this will realistically happen very often.
> 
> Yes, that's want I think too. Actually I don't want to encourage
> application developers to subclass those classes using the currently
> private members. Its more that I dislike this private-friends construction
> as currently implemented. I would rather make the members protected, but
> document them being internal and not to be used.

You know, after sleeping on it and thinking about it some more, 
I think I would prefer a mix of the two ideas better: have inter-
class dependencies continue to be reliant on friendship, but require
all class-to-class interactions to go through private accessor
methods (i.e. *no* direct access to private data members).

(The one exception to the rule would probably be BFilePanel, 
although I think that's really part of OpenTracker, and not 
something we'll actually be responsible for.)

----------------------------------------------------------------------
The arguments (+ = argument for; - = argument against):
----------------------------------------------------------------------

+ We don't have to expose any StorageKit:: members to the outside
world. Sure, they'll be visible in the headers (there's no way around
that), but they'll only be used in the private portions of our classes.
That gives us more freedom to do whatever we want with everything in
StorageKit::.

+ By using only accessor functions for inter-class interactions, the
person writing the class being accessed can worry about checking for
proper initialization, checking argument validity, etc. Thus we don't
all need a thoroughly intimate awareness of all the quirks of every
single class in the kit, just the ones for which each of us are 
personally responsible.

-/+ End-user developers can't create subclasses that are able to 
directly access the underlying implementation(s) of their 
superclass(es). However, due to the nature of our classes 
(encapsulations of a fixed set of functionality, all of which we 
already implement and expose via public interfaces), I don't think 
allowing end-user developers that kind of access is necessary, 
even for the case of creating subclasses. Furthermore, to do so 
would make it more difficult to change our internal implementation 
at a later time, should we ever desire to do so.

+ We don't have an interface lying around that end-user developers
are *able* to use, but are *encouraged* not to use (by this I mean
the protected interface). In a case like that, it's really just better
to not let them use it at all.

- A certain number of our classes will have unrestricted access to
the private data members of other classes. 

+ There are only a handful of us (six, currently :-) who are 
working on the classes, so it's a feasible task to make sure
everybody uses private accessor functions instead of directly 
messing with private data members in cases of inter-class 
interaction.

-/+ We're using friend, and I generally prefer to shy away from 
using friend classes. On the other hand, I think this is one of the 
few situations where friends are actually a better solution, provided 
they're used properly.

Thoughts, comments?

-Tyler

Other related posts: