TITLE: Classes, structs, and access rights (safety)


PROBLEM: mcrystal@bbn.com (M. Crystal)

The C method:
As a way of stopping *cooperative* people from accidentally modifying
a structure I can create a structure, a set of browsers (non-modifying)
for the structure, and a set of mutators for the structure.  Then I
create two .h files.  In one I specify only my browsers.  In the other,
I specify my mutators and include the browser .h file.  If my user is
willing to limit him/herself to my browsing and mutating functions, this
scheme adds security because someone who only wants to browse my structure
and includes only the browse .h file does not have the functions to
accidentally modify the structure.

In C++:
All function definitions are made in the class definition that resides in
a single .h file.  ***Is there a way of offering some users both browsing and
mutating functions, but limiting other users to just browsing functions as
I can do with includes files in C?***

I thought of creating a class, X, and defining only creation and browsing
functions for that class and then creating a subclass, X_mutable, to X
that adds mutators.  This, however, doesn't work because there are times
when I must declare a priori the type of my objects.  For example, consider
a class X that points to a list of Y instances.  Independent of how X
is used, mutable or immutable, I must declare the type of the Y-list
a priori?


RESPONSE: rmartin@rcmcon.com (Robert Martin), 6 Jan 94

Most of the time you can (and should) use an abstract base class which
declares your access functions  as pure virtual.  You can then derive
mutator classes from this.  

Most of your clients will not need to know about the mutators.
However those that create the mutators will need to know about them.
To break this dependency, you can take things one step further.

You have an abstract base class which specifies your access functions.
Derived from it you have another abstract base which specifies you
mutator functions as pure virtual.  Derived from this you have your
actual mutator classes.

You create an abstract base factory class which has pure virtual functions
which return pointers to either non-mutator or mutator abstract
interfaces.  You derive from this abstract base factory a concrete
factory which implements the creation functions with discrete
creations of the respective mutator classes.

Now your main program must create the discrete factory.  This is the
only module that needs a discrete dependency.  All others can deal
with abstract interfaces.  Monitor clients can deal with the monitor
interfaces.  Mutator clients can deal with the mutator interface.
Creating clients can deal with the abstract factory interface.

You can read about Factories in:

"Design Patterns: Abstraction and Reuse of Object-Oriented Design",
ECOOP-93, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.