[interfacekit] Re: BRoster & BWindow


> 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 don't see the problem in that! I think that the 'friend' keyword is
all to necessary making an API! In my opinion it is a bless to the
developers making that API!

    From now on I'll be referring as developers those developers making that
API, and users, as the developers using that API.

> >     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? What's wrong a class having 2 or more friends?
>
> 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!

> Obviously also Be Inc.
> realized that and hence introduced friends like `bool
> _is_valid_roster_mess_(bool)' in BRoster, `inline int32
> _get_object_token_(const BHandler *)' in BHandler, or `port_id
> _get_looper_port_(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.

    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!

You have omitted:
    inline void
        _set_message_target_(BMessage *message, int32 token,
                                            bool preferred);
    inline int32     _get_message_target_(BMessage *msg);

Now, if you put them near to:
    inline int32     _get_object_token_(const BHandler *);
    port_id          _get_looper_port_(const BLooper *);

you may see that, they can successfully be used by a BLooper derived class,
for targeting handlers!

> It would be BWindow::Private(window).xxxxxyyyy(...) to be precise.
    Yes, BWindow usually has multiple instances!

> If there are several occurences one would write:
>   BWindow::Private winPrivate(window);
>   winPrivate.xxxxxyyyy(...);
>   winPrivate.xxxxxyyyy2(...);
>   .
>   .
>   .
>
> >         or
> >     BWindow::Private().member; <----- ???!!!
>
> If possible, attributes should never be accessed directly by another
> class.

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

> 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_app->Team()). !!!

    That doesn't have to happen! Only classes that are part of the API can
do such changes, because they  KNOW  THEY  HAVE  TO, and the class that
allows those changes KNOWS its members are changed, and, MORE, it depends on
that.


> 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 ?!
NO! I do not agree with this design! Sorry! This is POOR design!


Adi.

Other related posts: