OOP Design Question

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
`

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: OOP Design Question

Set up autoloading:

http://php.net/manual/en/language.oop5.autoload.php

Cheers,
Rob.


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
> `
>

--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: OOP Design Question

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@garfieldtech.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: OOP Design Question

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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php