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.

And this is why we see so many static classes in the php world: People think classes are bags of functions. Go back to your OOP book and learn the basics (no offense) — HappyDeveloper, Oct 21 '11 at 15:53

davidethell · Accepted Answer · 2011-10-29T11:01:50.230

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.

Other advantages of treating things like database records as objects instead of arrays is that you have one place where the structure of that object is defined, which makes it alot easier to work on someone elses code than some random array. Also, if you document your code correctly, you can generate documentation right from your code. It also makes your code far more testable when it comes to unit testing. Furthermore once you've adopted an OOP way of thinking about code it's far easier to read someone elses code that codes the same way. The more you capsulate code into objects, the easier it — Christof, Oct 14 '11 at 12:20
..is to replace a part of your code for something else. Using a database as an example again, if you keep the components capsulated enough, you could e.g. switch from MySQL to Oracle without having to rewrite anything. Or if you're exporting data to some format, you could just swap out that XML generator with a JSON component if you want to start working with JSON. The real advantages of OOP will come to you the longer you work with PHP. — Christof, Oct 14 '11 at 12:23

score 2 · Answer 2 · answered Jan 22 '14 at 12:18

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.

php procedural with namespace vs oop

2 Answers2