View Full Version : How many of you use OOP with PHP?

12-06-2010, 08:24 AM
I'm relatively new with PHP, database and web apps.

After studying the language a bit, I noticed that PHP seems to encourage the procedural style although it gives you nearly 100% OOP functionality. Also from my understanding of how PHP works, I don't really see the need for OOP.

When a user logs in to your PHP app, a new session is automatically started. The variables and data in that session are automatically encapsulated / protected from other sessions. Its not easy to share data between sessions. So in a more traditioanl language, these sessions are like objects. Each user accessing your PHP program through the web server is like a new object.

Also, PHP has a whole slew of built in functions and these functions are not divided into classes or frameworks. There is no versions / extensions or polymorphed built in functions...

Also from what I understand, event listening and multi-threading isn't natively possible on PHP. Of course event monitoring and threading were two big reasons for OOP.

So I'm still planning to use OOP for PHP because it seems to be well supported. And there are other features in OOP such as extensibility (when planned right) and OOP forces you to name and organize everything properly.

So just wondering how many of you OOP with PHP?

12-06-2010, 09:47 AM
I don't really see the need for OOP.

There isn't any necessity for using it, to be honest. I use it in a fashion, mainly because it's a simple way of setting an accessible static var for all functions within a class instead of having to make it global or suchlike. It has its uses, but it's definitely not the be all and end all that some make it out to be.

multi-threading isn't natively possible on PHP.

Nope. That's my major annoyance with PHP.

12-06-2010, 11:04 AM
The ecommerce framework I'm developing has 63 classes, and 17 functions.

It depends how complex or adaptable you want to make your code. As an example, the payment processing system is a class. It's customised and the payment completion is managed by overriding certain functions inside that class, for example, you can extend the class, change the flow control in the constructor to place payment gathering before address gathering, unset a few countries and add a few card types. Et voila! You have a customised full checkout system in 3 lines of code. My Paypal code is an overridden constructor, an overridden doPaymentComplete and a new onPaypalIPN... That's it.

If it's a large project, and you plan it properly, OOP can be a massive help.