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 project. 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 http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1268432214&sr=8-1 On Tue, Jan 19, 2010 at 7:12 PM, Robert Cummings <robert@xxxxxxxxxxxxx> 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
