The object-oriented revolution has not been without controversy. Although many programmers embraced OOP quickly, others preferred the procedural approach they were used to, and wondered aloud if the extra machinery needed to support OOP wasn’t more trouble than it was worth. Still, there’s no doubt that the revolution has largely succeeded. Most of the popular programming languages in use today are either fully object-oriented or have object-oriented extensions. Also, at least some of the promises about improved productivity and increased code reuse seem to have been realized, as design methodologies like UML and patterns gain greater influence, and as people get more used to subclassing as a standard way to reuse and extend vendorsupplied libraries.
We feel that the benefits of OOP for “major” (that is, compiled) programming languages like Java and C++ are clear. On the other hand, we feel that the benefits of OOP for scripting languages (like Perl and PHP) are less obvious and are most debatable in the case of Web-scripting (PHP).
How is Web scripting different from other kinds of programming tasks? The most obvious difference is simply that Web scripts typically execute quickly and then go away. In other programming situations, you may have RAM-resident objects that live for hours or days and undergo complex evolutions of state that affect their behavior. A typical Web script, on the other hand, might execute for half a second, as it serves up a particular page, and then dies happy. You may knit these scripts together to provide a more extended user experience (using databases, sessions, cookies), but often such efforts are all about making the experience outlive any PHP objects that may or may not be created. More generally, scripting languages like PHP and Perl typically have a less thoroughgoing implementation of OOP than languages like Java, C++, and Smalltalk, and the limitations of implementation make these OOP extensions less attractive.
This is not to say that there aren’t still benefits of OOP in PHP. In addition to the conceptual benefits that may result from structuring code in an object-centered way, there are two good reasons to use PHP objects:
1) It’s a good way to distribute third-party code for reuse;
2) Many programmers who are used to OO syntax from other languages won’t feel comfortable unless they can use the same idioms in PHP.
But our main point is that use of PHP constructs for OOP is a very “tradeoffy” and pragmatic decision, which we have often seen made more on the basis of religion or fashion. If you are comfy with OO, this kind of syntax is there for you; and if you work in a group that has decided to write in that style, you may want to let the majority rule. If you decide not to go OO, however, be strong—we urge you not to be swayed by the moral-superiority arguments you may hear from people who disdain your five-line procedural script in favor of their ten-line OO script that does exactly the same task.
Taken from PHP and MYSQL Bible
It's often senseful to mix and match coding styles. Procedural can very well coexist with object-structured code, which for some tasks just looks nicer and explains the algorithm or processing cleaner.
ReplyDeleteHowever, in the PHP community there are very strong tendencies to cargo cult programming. Private methods and attributes make sense in Java, from where the idea was copied, but it adds little structural integrity in scripting languages (that's why Pythond eschewed them). But still, many PHP coders consider it "right OOP" to mark as many attributes as private as possible; neverminding that it only shadows underdesigned interfaces.
The likewise silly namespace\syntax also gets quite overused already. Deeply nested namespaces make sense in Java, but add little of the pleaded name conflict protection in PHP. It's just another syntax construct that gets used purposeless because it's hip.
Procedural works well for small projects and single-coder environments.
ReplyDeleteIn any place with two or more developers, you'll quickly find that class-type code reusability and portability makes for much more maintainable and scalable code.
Performance reasons aside, I'm not so sure a procedural based application would scale that well (team wise) as isnoop said.
ReplyDeleteI think the added benefits gained by using OO make up for the less inferior manner in which it is implemented in PHP vs Java etc. Reusability & maintainability are key in software development.
ReplyDeleteBy developing with OO in mind, you think more about how you are going to resolve the problem, thus (generally) making a better solution.
The dilemma is that, especially in teams, OOP provides a well structured paradigm. But PHP apps that adhere too closely to PoEAA, while well architected, need all sorts of beefy host upgrades to be performant. It's hard to get the balance right - and you have to know when:
ReplyDeletePHP !== Java
I had a similar stance on PHP OOP to the author about two years ago. I didn't fully understand PHP OOP at that time. The post strikes me as fairly naive, and I believe in two years the author will have a different opinion.
ReplyDeleteJust a sampling of OOP I could not do without today:
1. AutoLoader
2. Polymorphism
3. Inheritance
For any web app that does more than one thing, OOP is indespensible. Frankly I would not want to maintain a procedural app of any real size. I actually do have an app I developed three years ago 100% prodecural and I hate working in it now. It needs to be re-written.
My preferred style is the Rasmus Lerdorf approach: Procedural "controllers" with extensive use of objects when appropriate. Not EVERYTHING in your code needs to be an object.