Re: OOP Design Question
| From: | Larry Garfield | Date: | Sun, 20 Dec 2009 21:10:49 +0000 |
| Subject: | Re: OOP Design Question | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-300616@lists.php.net to get a copy of this message | ||
On Sunday 20 December 2009 1:08:46 pm you wrote:
> >> 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.
>
> Thanks for your insight.
>
> I could probably setup autoloading, but I wonder if I would do it
> 'properly'. Do you have a link or reference that you'd recommend for
> howto do a 'proper autoload setup'?
>
> Thanks,
> dK
Well, there is no universal agreement on what a "proper" setup is. :-) There
is a group trying to establish a Java-like standard for all projects to use
once they get to PHP 5.3 and namespaces, but there are still issues to work
out and IMO it's not actually a good approach for many use cases. I'd argue
that "proper" depends in a large part on your specific use case.
The most important aspect of a good autoload mechanism, though, is that it's
fast and extensible. Use spl_autoload_register() instead of __autoload(), and
make sure that you keep the runtime of your autoload callbacks to an absolute
minimum. (A DB hit per autoload, for instance, is a no-no.)
Beyond that, varies with your project.
--
Larry Garfield
larry@garfieldtech.com