The most important thing for a programmer in PHP, in my opinion, other than his experience is his toolkit. That is, code that he/she has written inside and out, backwards and forwards since time immemorial.
To me, in this instance, the advantage of OOP in clear. Having a class that you know will always preform what you want through simple methods is much easier for both yourself and team members, then it is by just calling a multitude of static functions. While you could argue a library of satic function includes serves the same purpose, in my opinion classes are much easier to read and understand. For example, in my custom session class a programmer can look at my code and see,
$my_session = new session();
$my_session->start();
if ( ($session_errno = $my_session->error()) !== FALSE)
{
//DO SOMETHING BECAUSE OF A SESSION ERROR
}
and easily understand that sessions in this application are handled via our custom session class, and should return some type of success/failure without having ever examined the library/class. Meanwhile, a call such as this,
session_start();
if (session_error())
{
//DO SOMETHING BECAUSE OF A SESSION ERROR
}
does not make it clear that session_start() is not a default PHP session handler, but that it will call the functions defined in session_set_save_handler() which was included in some mega list of global includes that might not be easily to locate in a large application. It is also not as clear that session_error() is a function that returns an error set by the custom session handler, vs a function that may actively look for session issues on an already generated session and is completely independent of PHP's default session.
This is not a great example, but I think it is a good one. I did not go into detail on the goodness that is protecting data from the application at whole, inheritance, and everything else that makes OOP useful.
But quickly, imagine a class that accesses an application's MYSQL database. A lot of time is spent designing the class to use prepared statements, log errors and provide proper logic to the programmer as needed. A team can worry less about database access issues by simply calling the class's public 'data access' functions without much concern about fatal errors, bad logic or dangerous SQL (injections and such).
This can all be done with static functions like you suggest, BUT every function in that static library is exposed to the application as a whole, while only the public and 'SAFE' functions are exposed to the application that uses a database access object. The programmer can not accidentally call a dangerous function that if not properly initialized by other functions could cause major issues, nor could the programmer deliberately suppress errors or other data protected by the class like they could with a slew of static functions and global variables.
While a good application can be designed without any objects, a good programmer should enjoy the usability, extensibility, and protections that objects afford when appropriate.
I'll leave with my final metaphor. Objects are like specialized machines and tools inside a factory. While the factory itself has a number of these unique tools on its assembly line, everything from simple bending brakes to CNC machines and automated robots, they are only a small part of the team that exists to help the more numerous laborers and managers, our static functions, do the job of building a better car, truck, or bike.
