In my current setup, the more classes Im adding to the code, the more complex things seem to get.Out of curiousity, what exactly are you trying to do? Are you sure this type of framework is most appropriate (and easiest to implement?)
For example.
I have a smarty object that has a reference to a DB object.
I plan on converting a file of user management functions to a class.
If I do, then that new class, is going to need a reference to the DB object.
Then on top of that, the smarty object is going to need a reference to the user management object.
By the time we are here, the smarty object contains a reference to the DB object, *and*
a reference to the user management object which contains a reference to the DB object.
And thats just the beginning. There are other classes that intertwine in this manner.
So what I would I forsee as a better playing ground would be
1. child classes being capable of talking to each other
For example, the smarty class capable of calling the DB class and the user management class
without the need for all those redundant *large* references.
2. The parent class capable of talking to the child classes.
In this context, parent and child is not to be thought of as in normal class structures where children *extends* parents.
All the *parent* class is, a means to provide wrappers around other *child* classes,
and act as a controller. The *child* methods/variables, aren't/shouldn't be called directly.
Also, if I can work it out, the class mm would only intially contain a constructor, and maybe a
class loader.
The class loader provides the additional class method wrappers on demand when needed.
This is merely an first rate idea. Nothing is remotely concrete about it.
Thanks for looking.
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
