OSNews

I tend to agree that OOP has been oversold, especially for the past decade. However, the pragmatic in me finds many uses for it. In fact, I would argue directly in opposition to Traal's post at the beginning of the thread. I think libraries are the most natural place to use OOP. (of course, we might mean different things by the term 'library')

For example, in PHP, HTML templates fill a very useful problem space. They don't solve all problems of logic/presentation interaction, but they are quite useful. Keeping your template logic inside a class makes it easier for templates to be widely deployed, even by people who have no idea what is going on inside the template code:
---------

require_once(templateClass.php);

$mypage &= new templateClass('/path/to/template.html');

//.. whatever complex logic I use to arrive at a value for $variable

$mypage->assignVar('MARKER', $variable);

$mypage->render();

---------

Now, if I had to do the same thing without OO, it would have to look like:

---------
require_once(templateFunctions.php);

$mypage = startTemplate('/path/to/template.html');

//other app logic...

assignTemplateVariable($mypage, 'MARKER', $variable);

//oops, now you have to pass $mypage by reference inside the
//function, so you modify the main $mypage variable and not a copy
//or, you have to constantly return the modified variable in full,
//as in $mypage = assignTemplateVariable($mypage, 'MARKER', $variable);
//which can be dangerous and counter-intuitive
//and you have to do more namespace-collision checking

---------

So you see how sometimes procedural methods can introduce unnecessary distractions in your main app flow. Even if your main application flow is procedural (which has its advantages in clarity and readibility), "side" issues like your database access and presentation concerns can be handled by classes. Basically, anything that you would like to swat aside like a fly, because it annoys you in your code could benefit from being encapsulated in a class somewhere.

Some of my criteris for the kinds of things to hide in classes tend to be:

1. if I am dealing with something annoying that distracts from my app flow, such as dealing with HTML, or configuration settings, etc...

2. if I want to maintain or protect the state of something I am dealing with -- for example, I have a class to access windows networks from Unix with by calling 'smbclient'. Now, that gets really messy, because each call to smbclient leaves you back at the root directory, so it is hard to navigate directory hierarchies in code. But, I maintain that state inside the class, using extra methods to put me where I should be each time, so the rest of my PHP code can interact with a Windows LAN just as naturally as with a local directory tree.

3. As a way to wrap up and render harmless some particularly messy piece of code inherited from a previous developer ;-). Haven't we all been there...?

4. When I want to think of a certain collection of data as sort of a 'complex' data type, which can be wrapped up and passed anywhere. Try that with only functions and you will get a headache fast (although it can be done).

Don't let anyone sell you OO purity as some sort of magic, but by the same token, don't be so quick to dispense with it. There are all kinds of reasons to use either one of procedural, functional (and yes, PHP has some functional abilities), and OOP. Really, I think each of us has certain mental predispositions to one or the other, but it is a good idea to learn a range of possibilities, so you can make an informed decision about which to use where.