Why and when would someone use OOP rather than procedural programming in PHP?

Question

I know some very basic PHP OOP (PHP: Hypertext Preprocessor object-oriented programming). However, I'm not sure why or when someone would ever really want to use it. It seems time consuming and in general unnecessary. Please give me examples on when one method would be better over the other. But mainly, why would you really ever want to use OOP in PHP?

Answer 1

The usual arguments for OOP vs. procedural apply. That is, procedural processing tends to offer few opportunities for code-recycling; the programs are frequently monolithic, top-down instruction-sets that are harder to maintain and evolve over time. Objects tend to provide small, manageable blocks of code that address small sets of specific concerns that can be reused. I prefer OOP in general, since I always have an eye to code reuse. However, size and complexity come into play, when making the decision as to which to apply for a particular project. When building an HTML page, the PHP most often looks very procedural in its most general structure, since the composition of a web-page has a very top-down order, i.e., head, head-child-elements, body, body-child-elements, etc. A simple, one-off page may be unworthy the heavier-weight engineering principles of OOP - where the line is drawn is a fuzzy issue. I note that the PHP-based CMS, Concrete5, that my shop employs widely on behalf of clients is a purely OOP implementation...very appropriately so, given the complexity of the app. There's a good "contrast and compare" article at:



http://devzone.zend.com/article/1236



That said, there is another approach you didn't consider explicitly in the statement of your question, namely Functional Programming (FP). FP provides the same potential for code reuse as OOP. It allows you to develop fairly small procedural-style blocks that rely on functions to perform the actual processing. If you really drink the FP kool-aid, you can make your top-level, "procedural" blocks be functions as well. So, even when I elect a more procedural model, I implement more of the processing in functions in order to offer recyclability...most often, I simply reuse existing functions, plugging them into top-level, director/controller procedural code. My shop mostly develops new apps using the J(2)EE Design Patterns (in PHP) for the web aspects and the GoF Design Patterns for the base operations. All of these are implemented in a mix of procedural and functional approaches. We write some pretty darned big apps this way, and still have a huge amount savings from recycled code; in fact, our entire project template is static and completely reusable. Individual "procedure" can vary at the level of the component-include or the functions employed. Joel has an amusing OOP vs. FP article at:



http://www.joelonsoftware.com/items/2006/08/01.html



I see potential and competing values in each model, depending on the nature of the individual project and the need and desire to avoid reinventing the wheel. As with most modern languages, the programming paradigm is up to the developer; each language supports all programming models, even when there may be a generally-preferred approach. Don't let anyone else's preferences lock you into a single choice of practices. Also, don't neglect learning new models just 'cuz you already know one...learn and grow, so that you have more options and CAN pick the right tool for the job.

Answer 2

Aric is right: for large programs, OOP may bring advantages.

The problem is WHEN to use it. If, like in his example, you use your sms call ONCE, just develop one function that has just that "send" feature. No need for classes, Objects or whatever.

However, in a large program making numerous SMS calls (example!), all over the code, and using several variances of that code (ie: send, receive, store msg etc), developing a class or an object that deals ONLY with that SMS will save you time. The "old" way would have been to write a "library".

The problem of these objects that, first, they usually are pretty large, second, that the user does not bother understanding WHAT the object does (or does not remember), and third, that it is totally useless to load a 5Mb class if you are using, ONCE, one single call to it! (wasted overhead).

Personally, I have found only one case where I am happy to have one: converting data extracted from a DB to put it in a PDF document, through Php. PDF encoding is a real pain in the ***. The class saves me time (But I had to understand EXACTLY how the class worked, what most coders would not bother to learn).

Answer 3

Baked Potato

Answer 4

For huge programs creating objects not only helps organize your code, but also helps improve effiency of your scripts.



I give you one example of how a class would be used.



network.sendsms("text message data","8009359395","sprint");



this is much easier. declaring an object is a little confusing but once you get a hang of it, you'll be glad I recommended it.