On Sunday 20 December 2009 10:35:56 am Daniel Kolbo wrote: > Hello PHPers, > > I have a collection of about 60 objects (class definitions). They are > all very similar. They all share a substantial % of the same core. But > they all have slight variations as well. The approach I took was to > make an abstract core class, and each of the 60 objects extends that > core. This works, but... > > Here's my problem, not every php/http request requires all 60 objects. > At this point, I do not know in advance which objects will be required, > so i include the class def of all 60 objects every time... I don't like > this idea as it seems a 'bloated' approach. > > So now i'm thinking instead i'll just have one object which has the > union of all the 60 objects' methods. But i'm not too happy with this > either b/c (i) now each instantiated object is carrying around a lot of > unneccessary baggage, (ii) i lose modularity of code, and (iii) the code > does not make as much 'intuitive' sense. For (iii), 'why does this > object have this method?' type questions another programmer would ask > (or me a year from now). The answer would be 'efficiency concerns', > which i'm aware that you generally don't want to compromise code > readability for efficiency if avoidable. > > Maybe this would be the perfect opportunity for the php autoload > functions...? > > Thanks for your help/thoughts/comments, > dK > ` Yep, this is a textbook case for a proper autoload setup. And no, cramming all of the functionality into one mega class won't get you any efficiency. In fact, it would be just as wasteful as loading all 60 classes even when you're only going to use 2; you're still loading up roughly the same amount of code. Parsing it as one mega class or one big parent with a few small child classes is about a break-even as far as performance goes, but the mega class is much poorer architecture. -- Larry Garfield larry@xxxxxxxxxxxxxxxx -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
