Double inheritance is lame. Flatten the class Hierarchy.

[GoogleCodeExporter]

Josh and I looked at the r15 doxygen-made class hierarchy together.  It's
more confusing than it is illuminating, which is a bad sign.  The biggest
problem is double inheritance of dotsAllSingletons along with
dotsAllRemotes or dotsQueryable.  Behaviors and therefore classes should
fall more naturally into groups with obvious superclasses.

The way to mix behaviors, like singleton and remote, is then to have some
classes register with managers that can provide extra features.

For example, dotsDrawable (subclass) instances would have to register with
dotsTheDrawableManager.  As a corollary, users would have to expect to
interact with dotsDrawables *through the manager*.  The manager could
decide whether to invoke methods locally or remotely.  It could do so in
efficient batches.  The drawables would only have to know that they have a
contract with the manager, and not that they might have counterparts on a
remote machine.

Another example--dotsQueryable (subclass) instances would register with
dotsTheQueryableManager.  When too many instances of e.g. dotsQueryableASL
were created, which should have singleton status, an error would happen. 
Better yet, users could expect to get dotsQueryable objects from a manager
factory method.

This might eliminate the concept of dotsAll*s superclasses, which are
confusing and not obviously different from other superclasses like
dotsDrawable or dotsQueryable.

It may make sense to have a dotsManager superclass, which would guarantee
and normalize things like singleton status, factory method, registration
method, managed object list, object UIDs, etc.

dotsRemoteManager might be a subclass of dotsManager, and handle things
like dotsDrawable or dotsPlayable.

The result should be a flatter, more illustrative class hierarchy.

Original issue reported on code.google.com by Benjamin.Heasly on 16 Dec 2009 at 10:07

[GoogleCodeExporter]

As a corollary to dotsManager, perhaps there should be a superclass of
dotsManagedObject.  It would guarantee and normalize things like constructor
registration and property listeners (to report changes to the manager).

It would also make clear that things like dotsDrawable are not free-standing
objects--they should be used through their managers.

Would all managed objects keep a handle to their manager?  Or just resolve it 
with
manager static methods?  I like the handle idea because the manager singleton 
could
be resolved once, at construct time.

Original comment by Benjamin.Heasly on 16 Dec 2009 at 10:14

[GoogleCodeExporter]

One concern I have is the growing number of singleton classes.  All that global 
state
is clumsy to test and not very OOP.

How many are too many?

But maybe there really is a lot of global state in this kind of hardware-rich
environment.  Screen, input devices, UDP sockets, machine settings, system 
modes--all
these things are global and all of them need to be managed.

Original comment by Benjamin.Heasly on 16 Dec 2009 at 10:22

[GoogleCodeExporter]

As of r43, there is no double inheritance.  There is a branch of singleton 
objects and a 
branch of managed objects.

Manager singletons deal with behaviors like remoteness and reuse of particular 
types of 
managed objects.

Original comment by Benjamin.Heasly on 29 Jan 2010 at 5:19

• Changed state: Fixed