Procedural versus OOP - Talk Me Into It!

[cngodles]

Ok, here is my dilemma. I've been a PHP writer for 5 years, have been getting paid to do it full time for almost 4. I recently missed a good opportunity because I didn't know enough OO PHP. Ok then, I say, lets learn it. So I printed out the OO PHP Part 1 tutorial, and I read a great article somewhere on the strengths and weaknesses.

 

It sucks that OO PHP is becoming sort of a standard. It's spliting PHP in half in terms of usage. I have to jump over to the better side and the split is the learning. If someone handed me an OO PHP class right now and said use it, I'd struggle big time. PHP is often praised for being super easy to learn.

 

I'm all for the learning. I've read the article twice, and I could probably spit out a good class right now.

 

I'm still having trouble justifing the extra work.

 

Within the past 2 years, I've started to develop entirely using functions. Everything I do is usually a function. I use this one a ton:

 

<?
function super_property($table, $id, $property){
$sql = "SELECT `$property` FROM `$table` WHERE `id` = '$id'";
$query = mysql_query($sql) or die("Cannot query the database.<br>" . mysql_error());
$result = mysql_fetch_array($query);
             return stripslashes($result[$property]);
}
?>

 

So I have a large function file that I use for most websites. In new projects I reuse a ton of them, and add in what is missing.

 

Now this thread is half gripe, half motivate me. In the end, I will learn OO php, and I will start to use it.

 

I'm just having a hard time finding the point. It's extra code. When I roll a function into a class, I have to add lots of $this-> in front of variables. Sure you can just call a class when you need it, but you can call a function list as well.

 

I'm sure you get a large amount of posts like this, so don't let me bother you. I think I just need encouragement either way, or some helpful tips for learning it and getting it down.

 

Thanks!

Clint

[trq]

I'm just having a hard time finding the point.

 

Its quite hard explaining the point too, just trust that once you know OOP your life should become allot easier. I'm no OOP expert, but Ive read enough about it to understand the priciples and can really see the binfits. Its just hard to see it untill you fully undertsand it. OOP isn't just about using classes. OOP makes it alot easier to develope good code using tested design patterns.

 

Of course, theres no need to use OOP in everything you do. Sometimes a simple email form is a simple email form.

 

However, anyone having a hard time undertsanding why OOP is worth learning would really benifit in taking a look at one of the more popular frameworks. Even having a quick read of the Zend Framework's getting started guide should give you hints as to its (OOP) usefullness.

[rhodesa]

I always recommend this site to people new to OOP: http://devzone.zend.com/node/view/id/638

 

And just like thorpe said, it's a strange concept to wrap your head around. But then one day, when you least expect it, everything will just fall into place, and it's like someone just flipped a light switch on. At that point, you fully appreciate OOP.

[roopurt18]

Pretend you design and sell models (aka figurines or something similar) for a living.

 

Procedural is like creating each and every model from scratch, even if it's the same figure.

 

OOP is like creating a single model (or bits of models) and casting them so you can re-create them any time you want to.

 

OOP is a tool, just like any other.  It has proper (and improper) uses.  Use it correctly and it will save you oodles of time and frustration.  Use it incorrectly and you wonder why you even bothered.

 

The trick is to just write OOP code.  Write a lot of it.  After each project you code in OOP, go back and revisit the principles of objects, such as polymorphism and inheritance.  In time it starts to make sense.

[cngodles]

I'll give http://devzone.zend.com/node/view/id/638 a try and see where it brings me. It looks a bit more promising.

 

Maybe one more thing I could ask. Say I'm programming a blog. In fact, I recently came up with a great set of functions for my best tag based blog yet. That's something I may reprogram in OO PHP. What are the possible benefits of doing a blog in OO PHP vs a function list?

 

And thanks for the encourangement and discussion. It helps big time.

[karpatzio]

Programming a blog in oo would be nothing more than creating a simple model, fashioning a few classes, controllers and eventually they would all just fall into place to form the whole application, which would then be easier to maintain and follow. The procedural approach is like a full front assault, it might and usually does work, but sometimes the details and complexity can overwhelm you reducing your productivity.

 

i guess this is less true to php as the applications tend to be smaller and spread across files anyway, but even here after you mess around with oo you will learn to appreciate it for larger scale applications.

[keeB]

http://nick.stinemates.org/wordpress/?p=26

 

Questions and comments are appreciated.

[JonnoTheDev]

OK. It seems that this is a confusion for many programmers regarding OO techniques. OO programming is NOT about putting all your functions

inside class files.

 

I'm just having a hard time finding the point. It's extra code. When I roll a function into a class, I have to add lots of $this-> in front of variables. Sure you can just call a class when you need it, but you can call a function list as well.

 

This is so far from the case! By simply "wrapping" functions inside a class i.e. class databaseQueries { } does not give you any or little benefit

from using a standard include functions file approach and may even add time to developing your application.

OO programming is about identifying the different parts of your application and how they relate to each other. Each part "or object" is created as a class

or a set of classes that may inherit or use functionality from other objects. I will give some examples further down.

 

Switching from a procedural style approach to an OO approach in your applications is another misconception for many developers.

It sucks that OO PHP is becoming sort of a standard

Whether you decide on an OO or procedural approach should be dependent on the type and scale of application being developed.

Also is the application going to grow with many new features being added or will it remain small with little modification?

If the application is small then a procedural approach is often the best, most cost effective and easy to implement. If the application is

intended to grow then a procedural approach may mean a less cost effective approach as it may take much longer to make modifications and additions

as appose to an OO designed application. Simply using an OO approach for the sake of it can also lead to issues withot proper design.

 

You firstly need to examine your previous applications and decide if they would have been better with an OO approach. Is there tons of if, else statements

in your functions and procedural code? Is there much code duplication in various files? How easy is it to add additional features to the application?

 

Lets take a couple of examples.

If I have an application that requires connections to more than 1 type of database lets say SQL and MYSQL. In the future this application may also need to

connect to more databases. This is the perfect case for an OO approach. If I did this procedurally I will probably end up with loads of if, else clauses

for each type of database. An OO approach may incorporate a Database super class and sub classes of MySQL and SQL. The type of object created or "instantiated"

in the code is dependent on the database connection string so:

 

$database = new database($connectionString);

$database->sendQuery(parameters);

 

The $database variable will contain either a MySQL or SQL object dependent on the value of $connectionString. New databases can be added by creating a

sub-class. There would be no need to modify any of the current code to deal with this unlike a procedural approach where functions and conditional

statements may need to be modified.

 

Another example may be a user system with different users having different levels of access. More types of users may need to be added for example admins,

accounts, sales, temps, etc. Adding new user types to a procedural system may be a nightmare if this is a common additional feature. In an OO approach you

may have a User super class that contains common details such as firstname, password, etc.. Then sub-classes of AdminUser, TempUser, SalesUser. The type

of object created may depend on the login details that the user supplied so:

 

$user = user::login($loginDetails);

$user->printSalesReport();

 

$user could be any type of user but this method would return false for TempUser meaning that they do not have access to the sales reports.

 

So in a nutshell if your applications require these sort of features and need to be extensible then an OO approach is the best. Good OO design is

not always easy to acheive and a knowledge of polymorphism, inheritence, interfaces, abstract classes, static methods and variables is required to create

the best design that fits your requirements.

 

On a final note for PHP development an OO approach is best implemented in PHP5. It is worth scrapping PHP4 and upgrading if not done already.