This is meant to be some kind of tutorial.
Oh well, here goes.
To solve any problem, you must first define it.
In order to design the best possible Manager class, we need to define what a Manager class is.
I am going to use a ParticleSystem to help you to better understand my meaning, but we're really designing a more generic 'BaseClass' from which you can derive ParticleSystems and much more.
Imagine that a ParticleSystem is a collection of Particle objects which all share a common Texture.
If we have 50,000 particles, we do not wish to load the texture 50,000 times, do we?
No - the ParticleSystem class would ensure that all the Particles it Manages share ONE loaded copy of the Texture resource.
So we might start defining a ParticleSystem class as such:
Object ParticleSystem, ParticleSystemID, Collection
We can see that the ParticleSystem class derives from the Collection class, so we have access to all those methods such as Insert and ItemAt. Its a Manager class, it manages a collection of Particles.
We might also begin defining the Particle class as such:
Object Particle, ParticleID, Primer
Great, you might think.. but it sucks.
Imagine that we have a fire that is ejecting big glowing coals.
They bounce on the floor, breaking up into smaller sparks.
Similarly, these smaller sparks break up on the floor into even smaller sparks.
To make this happen, each Particle must ALSO be a ParticleSystem.
IE, each Managed object must be a Manager to SubObjects.
We no longer wish to differentiate between Manager and Managed.
Wouldn't it be nice if our Manager could be derived from ITSELF?
Object ParticleSystem, ParticleSystemID, ParticleSystem
Firstly, that won't work - we can't inherit ourself.
Secondly, even if we could, we're no longer inheriting from Collection, so its a broken concept.
So how can we derive from ourself??
Let's stop talking about ParticleSystems for a moment, since that very specific example was only meant to illustrate a very abstract but common situation.
Take a look at this:
Object Manager, ManagerID, Collection
Object Managed, ManagedID, Manager
Manager is a BASECLASS which we don't really use directly.. we inherit its functionality in a Derived class.. and now it gets interesting.
The Managed class is derived from Manager.
Let's think about this.
A Managed object, stored in a parent Manager object, is also a Manager of children.
It took two classes (one base, one derived) to implement the mindboggling 'derived from self' hierarchical management concept, but we really can forget about the base object, and just worry about Managed and the classes we derive from it.
Now look at this:
Object Particle, ParticleID, Managed
Every Particle we create has the capability of storing SubParticles.
Each SubParticle can store its own SubParticles, and so on.
Now we can begin to define the generic Manager and Managed classes, and some specific example classes which derive from Managed.
Please let me know if you loved or hated this post :)
Pretty good mate. You have a syntax error in DefineVariablt pTex9,Pointer,NULL. Just a side note, if you step outside the framework (OA32) you can inherit from yourself. But it would be irrelevant to this topic as, like you stated, you'd loose Collections. Well, that is unless you made a "first time" exception which made the first class inherit Collections, then subsequent inherited classes skip over it. But in doing that you basically achieve the same thing as what you are doing here only with an unnoticeablely smaller executable and a lot of time wasted. :p