NYCPHP Meetup

[Hans Zaunere]

> > That certainly is half the battle; probably more IMO.  From initially
> > doing 95% of my code OO, I've leveled off at about 20%, if even that, and
> > have discovered better maintainability, performance and overall design.

--- Kenneth Dombrowski <kenneth at ylayali.net> wrote:
> I'm curious about that statement too.
> 
> I'm using objects very heavily, I guess about 95%, with good results on 
> small sites with low traffic.
> 
> Already maintenance seems to have improved over my old VBScript/ASP 
> code, which I had honed down to a pretty efficient set of subroutines in 
> #include files over the years, because of my personal preference for the 
> object design probably
> 
> But I have been wondering how it's going to scale performance-wise
> 

--- Ophir Prusak <ophir at prusak.com> wrote:
> Until now I have used very little OO PHP.
> I'm about to start a new project and was thinking of heavy usage of
> objects, but your quote now makes me think twice.
> 
> I'd very much like to know why you've dropped from 95% to about 20%.
> When is OO the best solution and when not.

Well as I'm sure many realize, these types of talks can turn religious very
quickly.  So, I'll try to keep it short and unbiased (ok, maybe not :)

<philosophy>
IMHO, Object Orientated design is exactly that... orientated towards objects.
 Some things fit nicely into objects and some things don't; for example I
find physical world entities can be represented nicely by objects in the
digital realm, as well as certain, well-defined process flows.
</philosophy>

While there has been a great progression in OOP to accommodate things that,
in my opinion, don't fit very well, PHP4 can still be considered limited when
it comes to these advanced OO techniques.  Overcoming these limitations incur
overhead, both computer related and human related..  Add that most
environments are very dynamic (especially intranets, where I spend most of my
time) and the encapsulation that OOD provides becomes more of a hindrance
than an asset.

Right now my general technique is to code the project out, procedurally, and
get all the requirements met with working and potentially production quality
software.  Then, as I start to see commonality and the potential for
encapsulation, either within the same project or across several, I'll fold
things together into classes.  Again, this often ends up being physical world
entities (i.e. patients, appointments, clinics, medical data, etc) and
well-defined processes (i.e. a patient has an appointment at a clinic,
appointments are cancelled, a patient is diagnosed, etc).  Generally I then
operate on the objects with functions and well-placed methods for enduring
operations of a particular entity.

It's a fine line, certainly.  IMHO, OOD, especially that available in PHP4,
lends itself best to static situations.  Dynamic jobs, such as reporting,
data-mining, etc. I find best accomplished with procedural design.  With PHP5
I'm expecting to increase OOD in certain regards.  Would well-defined
processes such as shopping carts, catalogs, etc. deserve larger OOD
percentages?  Sure.  But with the heterogeneous, "here today, gone tomorrow"
and "it's never finished" environments I'm mostly involved with, I've found
libraries are suited best, with procedural design giving the most
flexibility, and often performance.

Performance.  While I don't believe OOD is inherently slow, there is a
penalty... especially when you begin dealing with arrays of objects, nested
objects, and complex structures.  My primary sites are not high volume, but
they do incur fairly "heavy" volume.  So a single page hit could easily pull
5000 records from a 10 table Oracle join, pull 10000 from MySQL, mix them,
filter them, mash them, and then finally make the presentation.  I have done
these types of jobs with both OOD and procedurally, and notice that PHP loses
the "snappiness" it's renowned for with the former.

Lastly, Carlos makes an excellent point.  A lot is what you're comfortable
with, and what design logic your used too.  For me it's primarily procedure,
while for someone else it may be OO.  Above all, if it works well, it's good.

Best,


=====
Hans Zaunere
President, New York PHP
http://nyphp.org
hans at nyphp.org