[interfacekit] Re: BRoster & BWindow

> >     '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.
    Please, do understand, that, when implementing an API(personal use, or
OS wide), we know the possible values. There is no need for error checking
for method's arguments. WE, are not like an user of that API, in that, we
can introduce bad values; we have a specification upon making
implementation!
    As I see the things going on, in API development there are 3 categories
of methods:
    1) public: available to the user and also used for API development (...)
    2) totally private: used only by the class in question
    3) API private: used by the class in question, and by other API classes
that need to read/write some datas from/into this class.(As I see things,
that's exactly the purpose of BRoster::.UpdateActiveApp(...) [it's never
called in BRoster's implementation]). There is no way to do that, unless
using 'friend' keyword - at lest one! why not let the class to have multiple
friends that can modify its internals, following the specifications!?!
    Just curious! Where(in what API) did you saw private accessor classes
implemented???

> No matter if you develop an application (i.e. APIs that only you will
> use), or an OS wide set of APIs.
    Yes, that's right!

> >     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 '_' underscore is a hint (and the missing
> documentation as well) that these functions are indeed private, and not
> of much use for others.
    Oh no! Believe me, they are much of use in BWindow class, that is, a
class that is derived from BLooper!

> 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.
    I  DO  AGREE  HERE!!! We should put all there functions into a class and
make that class a friend for all classes these functions access!

> >     !!! 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.
    WHY? To complicate the code? And what should I write in that function?
void ClassPrivate::SetAttr( void* arg ){
        class.member = arg; }
void* ClassPrivate::GetAttr( ){
        class.member = arg; }

    Just and assignment??? and then:
    ClassPrivate        *cp = new ClassPrivate( class );
    cp->SetAttr( value );
    value = cp->GetAttr();

Thank you, I prefer the quickest and clearer way.
And notice that most of the time, I, the API developer, do a call with valid
values!

> > > 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,
    My point.

> not the general API as well.
    Who said that??

    So you see, again 'friends'! That is what I am saying. If a class knows
that an API class needs its services, it should include that class into its
friends list! It knows that class will modify its members according to
specifications!

> > > 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 :-)
    :-) I don't know why, but I do agree. :-)

> Direct member access is a major pain in every class library you write.
    YES, it is! ... when you are in public area !

> 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.
    Let me say that, I do agree with that affirmation! But, ( there always
is a but. :-) it does not always apply! I cannot use an private accessor
classes between BWindow an BView! It complicates things! It is BWindow who
manages some of BView's members; BView only access them(I don't know for
sure now, but I think there are some members that BView doesn't even read or
write!).


PS: an example! This I consider poor design:

class BRoster{
private:
    friend RosterPrivate;
}

class RosterPrivate{
private:
    friend BWindow;
    void UpdateActiveApp(...){
        roster->UpdateActiveApp(...) // that's all !!!
    }
}

What is point in that??? The same would go for a LOT of BWindowInternals
methods, if implemented!


Adi.

Other related posts: