[interfacekit] Re: An idea

Why generate a whole new layer between each class? By doing so we will
have twice the number of classes in the current InterfaceKit and 50% of
them will be merely pointing back to an original class' functionality.

--Mark Tinderholt 
mtinderholt@xxxxxxxxxxx

-----Original Message-----
From: interfacekit-bounce@xxxxxxxxxxxxx
[mailto:interfacekit-bounce@xxxxxxxxxxxxx] On Behalf Of Erik Jakowatz
Sent: Thursday, October 11, 2001 4:22 AM
To: interface kit team
Subject: [interfacekit] An idea


I've noticed in reviewing the App and Interface Kits that a large number

of classes are friends with other classes.  While I realize that this is

mostly happening between core kit classes that need to interact at a 
more intimate level than C++ access specifiers alone can manage, I find 
it personally disturbing when a class has a list of 6 friend classes. ;)

So here's what I'd like to propose:

Rather than making all of these core classes friends of each other, we 
define an opaque class that "friendly" classes use to access the guts of

other classes.  For instance, BView is a friend of BWindow in the 
existing API.  Instead of that, we define a class BWindowInternals.  
This class is the only friend BWindow has (poor BWindow! ;) and it has 
accessors/setters/getters/etc. that BView & Co. can use for twiddling 
BWindow's private parts.  BWindowInternals is a private class of the 
Interface Kit -- neither the declaration nor the definition are part of 
the public API -- and could even live in the BPrivate namespace.  Yes, I

know; it's opensource so we're not *really* hiding anything from 
anybody, but it's much better design practice, and should drastically 
cut down on dependencies.  This method allows us to give an extra level 
of access to those core classes which need it, but still insulate those 
classes from internal implementation details.

Anyway, unless anybody has a major objection, this is how I'd like to 
see things get implemented.  Comments?

e

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: