[interfacekit] Re: BRoster & BWindow

"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
> > Extensive use of friends indicates poor design. As said above, a 
> > friend
> > has full access to the class. This is a flaw of the C++ language
> > obfuscating the access permission concept.
>     'friend' keyword is used for easing access between classes witch 
> know
> one about other!!!  I do not see it as a flaw, but as a very 
> comfortable
> shortcut in API development! I do agree with you that it is 
> obfuscating the
> access permission concept, but this does not apply to API 
> development,
> because classes need to cooperate!

Sure, they need to cooperate - through private class accessors.
Using "friend" extensively destroys the class encapsulation, one of the 
most important things in object oriented programming.
The private accessor classes clearly define which values are allowed to 
be accessed, and how. This is a very important advantage in designing 
huge classes.
No matter if you develop an application (i.e. APIs that only you will 
use), or an OS wide set of APIs.

>     If you look again you'll see that those functions are accessible 
> by
> EVERY class that is constructed !!! Those functions are listed, as I 
> see it,
> because, the user may need to access such members sometimes! They 
> were not
> introduced because friends indicate a poor design or that they are a 
> flaw in
> C++ language!

But it is, no matter the original intend of the class designer. 
Furthermure, the '=5F' underscore is a hint (and the missing 
documentation as well) that these functions are indeed private, and not 
of much use for others.
That they are usable for all classes is in fact a design flaw in that 
class, and that's caused because "friends" don't have a scope in C++ - 
which is a design flaw in C++ and requires the private accessor 
classes.

>     !!! BWindows class is responsible for building the view tree! IT 
> MUST
> access those members directly !!!

Not really, an accessor function is as good as direct access in that 
sense.

> > Accessor methods are the way to go -- they add much more
> > flexibility.
>     That is (!) not the case when building an API ! We already have 
> the
> specifications, we already know the possible values! there is no 
> reason for
> that kind of flexibility here! The user never has to access those 
> members!
> OR, in your BRoster implementation, ANY class can make the call:
>     BRoster::Private().UpdateActiveApp(be=5Fapp->Team()). !!!

The private class can be the friend of those who should know only, not 
the general API as well.

> > Aside from that the the second version wouldn't work anyway,
> > since you don't want to access a member of the helper class, but of 
> > the
> > real one.
>     Right! I was in a hurry, I didn't thought more about! But, now, 
> I'm
> a little amazed! As I understood, for every member that want to
> access/modify I have to put a method in BXXXXInternals =3F!
> NO! I do not agree with this design! Sorry! This is POOR design!

It's not poor design, it only looks like poor design :-)
Direct member access is a major pain in every class library you write. 
It's just so easy and nice that everybody does it for small (or his 
own) classes.
It's not recommendable for a public and huge API like the BeAPI is.

Adios...
   Axel.

Other related posts: