It's often a sledgehammer to crack a nut
Agreed . . . and what I've found is the class methods are often more confusing than direct methods in a procedural framework. For example, a query using a class for database connections might be like
$result = $db->query($query);
To get to this point, you have to learn all the functions in the class, learn all the parameters it expects, what format to send them in, what return values to expect . . . and have to do this for every class you use. We've already learned PHP, and now we have to learn the language of the classes we use, and it never ends. With every class you incorporate, you have to learn a whole new sub-language.
$result = mysql_query($query);
Another aspect of OOP I don't like is many classes I've worked with lack customizable function or output. Say you have a class that works perfectly for what you want but outputs tabled layout or invalid HTML (don't laugh. I've seen it.) Do you hack the class, or find another, and how much time do you spend doing that in the interest of thumping your "must be OOP" doctrine? Personally there's nothing I find more frustrating than modifying someone else's code, trying to thread through their logic, just to get the output that I want or that the project requires.
If you have thousands of lines of code . . .
This
can be false (although, in many cases, it's not.) I use a method that is inherently procedural, but pares off most of it's coding in functions, which moves toward the advantages of OOP, but it's still considered procedural.
Let's say the entire program is this (which it usually is)
if (isset($_POST['function'])) {
$func = $_POST['function'];
$func();
}
else if (isset($_POST['display'])) {
output_html($_POST['display'],null);
}
else {
output_html('entry_page_html',null);
}
That's it, the entire program "controller." From this you can see we have one function (output_html) and another that may be a variable function* based on input. For output_html, the required parameter is the page state/title, an optional error parameter, and has no return value; it outputs and exits.
The variable functions can be anything, for example, "ud_db" which may map* to an update database function. When complete, this function will call output_html again, and pass a title and possible an error variable. Within this function, I may call many other functions - for example,
$input_errors = cleanse_input_data($_POST);
which is a function that can be used from almost any other area of the program.
Functions, like classes, are "black boxes." You pass a value to them, and they usually return a value. They must stand on their own,
without depending on global variables to function, and must contain their own internal error handling (that is, it the parameter values are of the wrong type you need to handle that condition.)
But still, it's basically a procedural way of working. Purists would discount this method and say "it should be OOP, that's what real programmers do."
Sometimes OOP is just overhead.
* Of course, the raw post input is always cleansed and filtered, and you'd never want to reveal a function name in a public query. Generally I map these to "allowed values" in a global include.
