What is the point of object oriented PHP?

It is important. And, you've actually been (unbeknownst to you) been benefiting from it in the PHP you've written thus-far.

Consider this: when you create a variable that contains a string, you can take for granted that the variable will have certain "abilities". You can treat it like an array and pick a letter out of wherever you want in the variable. You can iterate over each letter in it. You can pop letters off the end of it. You can extract a substring from it. You can convert it to upper case or lower case. You can concatenate it with another string. All of this is possible because a "string" is an object in php and in addition to it's contents, it also has available to it all of the methods available to strings.

By creating objects yourself (in your programs), you too can encapsulate (group together) both data, and methods that can be used to access and manipulate that data. This makes any code you write for a particular type of data easier to maintain and reuse.

I was once asked by someone studying mathematics on Khan Academy "How much math is really necessary? Will I ever USE Algebra"? My answer was: If you only know addition and subtraction, you'll only ever see how addition and subtraction opportunities in real life. Once you learn multiplication and division, you'll find they come in handy all the time. The same goes for Algebra. The same for Calculus. The more you know, the more you'll find use for. You can use it all, if you know it.

The same concept applies here - once you know the ins and outs of object oriented programming it will just plain make sense to use it.

On a more practical note: If you want to be HIRED to write PHP today, 90% of the jobs will be asking you to work with a framework (such as CodeIgniter, Laravel, Yii, etc) and they are all based in the object oriented paradigm. If you don't know it, you'll be significantly limited.

I think it depends on the scale of the project. For a small project, functions may suffice. However, if you were to create a larger project that may have hundreds of users for example, then procedural programming may be messy.

For example on a personal website, or blog where there's very few users, procedural programming may work fine.

However if you're building an application where you can expect hundreds of users, then we can see the benefits of OOP. We could make one base class called User. User may have some generic capabilities like:

• Name
• Profile page
• Email address
• Add friends
• Make post
• etc...

These are some basic functions we believe ever user should have. Now we must consider things like Admin and Moderator. Of course, we want these two user types to have the basic functionalities of an average user. However, there should be some other perks involved like:

• Edit user post
• Ban user
• etc..

Using procedural programming, I would take all those capabilities of an average user and manually apply them to the superusers. Using OOP inheritance, I could specify that superuser is a child of user, letting it be known that anything user has, superuser will have.

Here's some posts that explain the benefits in more detail:

http://stackoverflow.com/questions/716412/why-use-php-oop-over-basic-functions-and-when

http://www.phpclasses.org/blog/post/178-Why-is-it-better-to-develop-in-PHP-with-classes-OOP.html

It is important for just about every programmer to understand the ideas behind OOP.

For a simple application, yes, perhaps tossing in some if statements will get you what you need.

However, on a complex application, with many user types and capabilities which may change over time, OOP begins to really shine.

For instance: Say you pepper the code with "if user == moderator" calls for all the variety of things only a moderator can do. What happens if later, another type of user is added who can only do a subset of the things allowable to a moderator? Do you then go in and check every if statement in the entire code base to check and see if that other user type should be added to it?

If instead, you had a moderator class (that inherits from a user class) with properties such as "can_edit", "can_delete", "can_archive", "can_flag" and the if statements in the code didn't check "if user == moderator" but instead checked "if user.can_edit", you have much more freedom to later add another type of user who could (for instance) flag an entry but not edit it, without having to sort through every if statement in the entire project.

I have a different take on the benefits of OOP. Properly done with Namespaces, your code becomes completely portable from project to project. You could write code for user registration (for example) and use it on any project. Or you could use Composer and use someone else's code and save you the trouble of writing your own.

With respect to small projects, OOP provides a much better way to organize your code. If you have a class for each major area of functionality, it is easy to find and edit the code in any given area of functionality. You can have a database class and know that all database functionality is in that class. You can then write your site and pass the information into the class without having to repeat the code in multiple places. And if there is a bug, you know exactly where you have to go to fix it and you only have to go one place. Overall, it is much simpler to figure out.

OOP also helps if you or another developer has to add functionality in the future. The code will likely be better organized and easier to read for the future edits.

These benefits lead me to believe that using OOP in any size project is the best practice and I am trying to implement it in all of my projects.