[interfacekit] Re: BRoster & BWindow

"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
> 
> "Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
> > > Hello Ingo!
> > >
> > > Ingo, I want to make the following call:
> > >     be=5Froster->UpdateActiveApp( be=5Fapp->Team() );
> > >
> > > BRoster::UpdateActiveApp( tead=5Fid );
> > >     is private. I see that BWindow is not a friend of BRoster.
> > > What should I do=3F
> 
> > Sorry, I forgot to mention that.
> > To clean up the mess a bit, I removed
> > all of BRoster's friends, save a new class BRoster::Private
> > (declared in headers/private/app/RosterPrivate.h).
> > Just add a UpdateActiveApp() method there, that simply
> > invokes the roster's private method. Then, you can call
> > BRoster::Private().UpdateActiveApp(be=5Fapp->Team()).
> 
>     It seems to me that you've complicated things! What's wrong in 
> BRoster
> having BWindow as a friend=3F

BRoster had a list of not less than ten friends (lucky BRoster ;-). All 
of which had full access to all members of the class.

>     I've read "An Idea" topic Erik opened in Oct 2001, and I must 
> say, that,
> I do not agree! Why is it you guys do not want to see more than 2 
> friends
> for a class=3F What's wrong a class having 2 or more friends=3F

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. Obviously also Be Inc. 
realized that and hence introduced friends like `bool 
=5Fis=5Fvalid=5Froster=5Fmess=5F(bool)' in BRoster, `inline int32 
=5Fget=5Fobject=5Ftoken=5F(const BHandler *)' in BHandler, or `port=5Fid 
=5Fget=5Flooper=5Fport=5F(const BLooper *)' in BLooper (to name only some), 
which allowed other classes to access only a certain aspect of the 
concerned class. The approach to encapsulate those selective accessor 
friends in a single class is just consequent.

> Image, if I
> would implement, as Erik said, the BWindowInternals class. By the 
> number of
> private method calls and private member access between BView and 
> BWindow(
> also valuable for BWindow - BView), I would have to write dozens of 
> new
> lines! And those lines would look like the one Ingo wrote to me:
>     BWindow::Private().xxxxxyyyy(...);

It would be BWindow::Private(window).xxxxxyyyy(...) to be precise.
If there are several occurences one would write:
  BWindow::Private winPrivate(window);
  winPrivate.xxxxxyyyy(...);
  winPrivate.xxxxxyyyy2(...);
  .
  .
  .

>         or
>     BWindow::Private().member; <----- =3F=3F=3F!!!

If possible, attributes should never be accessed directly by another 
class. Accessor methods are the way to go -- they add much more 
flexibility. Aside from that 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.

>     Come on... that is no way to write a clear source code!!!

It makes the use of a private interface more explicit, one could argue 
-- analogously to the use of {static,dynamic,const,reinterpret}=5Fcast<>
() instead of the C cast...

CU, Ingo

Other related posts: