[nycphp-talk] Per-/con-ceptual problems with object orientation code loading

Eliot Shepard eshepard at
Tue Jun 18 16:16:55 EDT 2002

> The problem with loading an object class is that people don't know
> how to break up a class to save their gonads and keep trying to
> define a class as a single file which results in a lot of unused code
> being loaded and inter-piled uselessly.

Not if you use an shared memory compiled-code cache like Zend Accelerator
or PHP Accelerator ( Cuts out both load
from disk and compilation. Latter is a great free product BTW.

> Ever thought of breaking up the code into one __directory__ per class
> containing one file for the static object definition (the Class and
> instance variables that all the methods will depend on,) and one file
> per method with an "IncludeOnce" pragma of the static definition?
> (Sorry if I'm showing my "Ada" but I learned about Pragmas reading
> the DND "Green Book.")

Sounds like a maintenance and usefulness nightmare, which would undercut a
lot of the benefits of OO design. It also would seem to have bad
worst-case performance (where you need a lot of the class' functionality.)

If your classes are too big, you might be at the point where you can
abstract stuff out into a base class or generalized utility functions.
That's the trigger I look for.

> The same principles of optimization still apply:
> 1) Don't execute any instructions or allocate any storage you don't
> absolutely need to. (Make it fast) (This is the WORST offender and a
> measure of how lousy programmers are at designing efficient
> algorithms. M$ Windows makes me weep. At least the Mac only let you
> fill a TERec (TextEditing pane model object) with a maximum of 4K
> Bytes. Windows would acept megabytes of data even though it could
> only show one or two K of it. What a waste of time. Bill Gates owes
> me HOURS!)
> 2) Never execute any code twice when you can cache the result. (Make
> it faster)
> 3) Never cache a result you won't reuse. (Make it smaller.)

4) Never overconcern yourself with optimality before profiling.
5) Never create the potential for bugs by trying to make every code path

Just some thoughts. Thanks for an entertaining post.


Eliot Shepard

More information about the talk mailing list