php procedural with namespace vs oop

Question

The biggest advantage of the OOP vs procedural programming in PHP to my understanding is the sort of separation of the function names (sort of namespace).

So now when we have namespace since version 5.3, what do you think - For most cases (small to mid websites), when we need fast and again structured code, do the use of namespace + prodecural programming gains signifficant advantage over defining and writing in OOP.

Advantages:

• structured
• faster code/development
• again we can define something like private functions within the namespace starting with "_" knowing that we don't need to use them
• etc..

Code example:

namespace User;

function setPassword ($user_id) {

    $pass = _generatePassword();

    $sql = 'UPDATE `users` SET `password` = '.escape($pass).' WHERE `user_id` = '.escape($user_id);
    $result = mysql_query($sql);


    if (mysql_affected_rows() == 1) return $sql;
    else return $sql;
}

function _generatePassword () {

    $char = '0123456789abcdefghijklmnopqrstuvwxyz';
    $str = '';
    for ($i = 1; $i <= 6; $i++) {
        $str .= $char[mt_rand(0, strlen($char))];
    }

    return $str;
}

Usage:

$user_id = 5;
User\setPassword($user_id);

I am asking for opinion. I know that it is just to the developers style, but maybe I am missing something.

PS. For most cases (small to mid websites) - I mean when you do websites for clients which are mostly 1 time development, and a little feature improvements in the long run.

Answer 1

You are thinking of OOP the wrong way. If you are trying to compare OOP with procedural namespaces merely as two different ways of organizing your code and function calls then certainly namespaces will seem more efficient.

The advantage of OOP isn't in organizing an object full of functions. That just treats OOP classes as big "utils" classes full of functions. The advantage of OOP isn't organizational. It is an entirely different way of building your programs that causes you to break your code into smaller, discreet entities. I use OOP in all of my PHP programs, even for small projects.

The advantage of OOP becomes most clear for me when doing any project that accesses a database (which is pretty well everything nowdays). I create small classes to model each database table and then access the information in these tables as objects. I have some base classes I use in all my projects that define how to map tables to objects so I don't retype or paste mysql commands any more. I just use the objects and they inherit all the needed functionality for inserting, updating and deleting from the database.

It sure is far more useful in code (especially if you use a PHP ide that has code completion) to see this in code:

echo "Hello, {$someDataObject->name}!";

Than this:

echo "Hello, " . $row['name'] . "!";

The difference might not be obvious right away. Both examples are a single line of code to print a table column. But the second example requires that I know the column names in my head. The first example has the column names embedded in the classes as properties. My code inspector knows all the properties so when I code it presents a list of all the properties as I type.

Maintaining the classes is easier than you think. Depending on the object framework you choose there are scripts to generate classes from tables and keep them up to date. And I find it FAR less error and bug prone to keep my object classes up to date myself than to have database changes break code because column names changed and then I have to update those column references in dozens of places. Yes, there is search and replace, but do you see the advantage of updating one file for your column change than updating every reference to $row['some_column']?

I hope this helps answer your question.

Answer 2

I think it is a valid question. With OOP style programming there tends to be a lot of overhead introduced as the problem space grows and the code base increases. It's fair to say that for small sized projects, there isn't any real difference between using OOP, functional or procedural, but this is not the case thereafter.

One of the advantages, although not the only one, touted by OOP programming doctrine is the benefit that namespacing gives you. Also, forcing the use of classes introduces another level of closer coupling and some dependancies in a lot of cases. What is proposed here is to write procedural code using only namespaces, which will allow reuse of functions in a much more natural way.

It's hard to be more concrete in the general case, and the examples presented in the original question don't reveal some of the potential benefit of avoiding the use of classes for the reasons mentioned.

Some of the arguments for not using an OOP style are more comparable with the arguments for and against functional programming languages. An interesting example to add here would be to look at the relatively new go language, written by the guys at google, which goes one step further and allows functions to be defined separate from structs or interfaces, using packages in their own namespace.

If the guys at google see some merit in the approach presented here, for my money, it doesn't seem such a bad thing to consider, and more than food for thought.