object oriented programming

[Ninjakreborn]

I have been thinking about this steadily for a few months.

Literally what is the difference between building a site with regular php programming, as opposed to Object Oriented PHP Programming.  What is the difference.  When I write regular code, ti get's pretty advanced at time's, but everything is always neat.  What's wierd even when I know someone uses OOP a lot they don't seem to be using it for regular web projects. 

I also don't understand the concept behind OOP, are they like functions on steriod's, with just a quicker way to call them when needed or something.

[Jenk]

Modularity, Maintainability, Extensibility, Reuseability.

Just a few of the advantages of OOP/D over 'procedural'

[obsidian]

[quote author=Jenk link=topic=114927.msg467763#msg467763 date=1163510317]
Modularity, Maintainability, Extensibility, Reuseability.

Just a few of the advantages of OOP/D over 'procedural'
[/quote]

All of these words Jenk uses are very precise answers to your question, but I'll give you a little more [i]personal[/i] reason since that's what I typically like to hear as well ;) ... Think on it this way: when you write [b]procedural[/b] or [b]linear[/b] code, if you're honest with yourself, you find yourself having very similar code on multiple pages. For one thing, you'll be running the exact same query combinations and output calls and sometimes even parsing strings over and over again. If you take a step back and start writing classes to handle layout and queries and yes, even string parsing, you will very quickly notice an incredible cut in amount of code. It takes a [b]lot[/b] more planning and forethought, but it's incredibly easier to maintain in the long run. If you have one string parser class that you use throughout your code to display data, you simply have to update one location, and all your pages will be updated concurrently. Very quickly you can see the benefits if you've ever used it before.

My favorite aspect of the OOP model so far is simply the [b]Reusability[/b] aspect. I have written a couple different user classes that handle everything from logins to session handling, and between the ones I've written, I've been able to apply them to close to a dozen different projects. Just plug it in, and off you go! In my most recent one, I discovered the power of PHP5 to a new level as well. I love it when my entire login script consists of the following lines:
[code]
<?php
try {
  $User = new User($MyDB);
  $User->loginUser($user, $pass);
} catch (Exception $e) {
  $error = $e->getMessage();
}
?>
[/code]

The classes used in the few lines above handle everything from error checking to logging the user in and redirecting them to the appropriate pages based on access credentials. That could [b]never[/b] be done so simply with procedural coding.

[redbullmarky]

as Jenk says.
I'm relatively new to OOP in PHP, but essentially a class COULD very well be a function on speed. moreso, an object's entire behaviour can be changed on the fly. a good example i've seen in the past was an 'Output' class - whereby giving it a little tweak, it could handle output to the screen, printer, plain text, etc. Sure, you could do that with a function - passing it a parameter, etc - but what happens to all your code when you decide to change the type/amount of parameters the function requires? yup - broken.

you can probably achieve much the same in terms of the final output with either OOP or FOP, but in terms of the 4 areas Jenk mentioned, it's OOP all the way.

cheers
Mark

[printf]

To me object oriented coding has some good points in regards to code manageability, but that is where it ends. Why, because PHP is stateless it can not maintain a object or reference to an object without serialization, so what's the point of being so excited over the object approach as apposed to procedural approach seeing you still need to reload all the classes, methods and properties with each new scripting call. Java's idea along with COM, .NET give you a real object based system, because you can maintain the object state across the entire lifetime of the servers instance, which is where the true power of object based programming becomes very powerful.

Sure in PHP you can partly mimic this using serialization, but it so far from having the same objects already loaded with each script call, initialization with unneeded IO calls is a big penalty that makes PHP not as robust as other object oriented languages. But as I said and other have stated, that manageability makes using object oriented style so much better than the procedural way. But that still does not mean, that everything you do should be object based, because creating a class to do trivial things is down right silly.

[Jenk]

printf, that is not true.

Object Oriented programming and design is by no means at all bound by the need to maintain state of objects across multiple interactions. Infact, there are less circumstances where maintaining state is necessary over multiple requests, than there is unecessary.

I'll also add that COM and *.NET also have to serialise objects, and you have to register those objects for state maintenance in the session. As does PHP, so in true essence that argument is moot. [code]$_SESSION['object'] = new Object;[/code] vs [code]Session('Object') = new Object();[/code]

It is HTTP that is stateless, not PHP/*.NET/COM.

[roopurt18]

I tend to limit my use of OOP in PHP to general mechanisms within my site.  I.E. typical objects within my site tend to be CPage, CForm, CAccount, CUser, CComponent, etc.  I put as much base functionality into each of these objects as necessary and use them as a base class when I find a situation in which a object needs a more specific functionality.

As an example, my last CForm class allowed me to set the fields of the form, which routines would validate each field, the creation of all form related HTML, etc.  Then when I needed to create a new form in my site, I'd derive a new class from CForm, specify in the constructor which fields the new form contained and which routines to use to validate it, and just like that I have a new form on my site.  It automatically knows how to display itself, how to display default values when re-displaying itself because of a form error, etc.

I tend to not use objects when pulling data from a database.  9 times out of 10 when I pull data from a database it's merely for displaying and I find the arrays returned by the MySQL functions sufficient for this task.