I also agree OOP is not a fad. Its a step up from procedural/including.
And it's still evolving.

While PHP is able to do polymorphism perfectly without OOP/classes,
through "require($plugin/className); $varFunctionName ($p1, $p2,
etc);", My newsscraper works very well that way.
But if you want inheritance features it's best to cross into OOP land.

A MVC app (front scripts that forward functionality to many other
scripts) does not have to include dozens of scripts to get things
done. You can require_once() the functionality that you need within
switch($command) statements.
Bytecachers and compilers furher reduce this problem (to
insignificance as far as i'm concerned).

But in my 20+ yrs exp, OOP-ing everything in an app from the start
costs too much (wasted) design time in the first half of any large
So i've reverted back to sticking to procedural programming for nearly
everything, except well walled-off problems that scream "OOP me".

For my own CMS i first had designed classes to handle the
businesslogic near the database level (a dossier class containing refs
to media-item classes for instance), but as my CMS was evolving i was
spending too much time re-and-re-designing those dossier and media
classes. The conflict between "a well written class" and "a class that
does what i need atm" kept popping up.
I found that using functions and arrays as return/command "objects" is
much nimbler.
I get things done quicker not OOP-ing.
But i bet some other programmers prefer OOP over procedural for the same reason.

I do use OOP-ed objects for several of my subsystems (adodb.sf.net is
my current favorite), and if i have a small app to share (especially
in javascript) then i put it in an object, for namespace cleanness.

OP: if you want to use OOP to it's max, read

On Tue, Jan 19, 2010 at 7:12 PM, Robert Cummings <rob...@interjinn.com> wrote:
> I would have to agree that OOP is not a fad, perhaps over-hyped at times,
> but definitely not a fad. The argument about class dependencies is an
> invalid argument since functions will also have dependencies on other
> functions from other libraries, quite likely located in multiple source
> files. In fact, you've argued an advantage for OOP in the context of PHP
> since autoload can be used to mitigate this issue for classes, but not for
> functions. Another advantage of OOP that is difficult to provide via the
> procedural paradigm is polymorphism.

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

Reply via email to