Forum Moderators: coopster
OOP is ideal for a bit bigger projects, as they normally consume more resources and time to code them. Many do it for the clean structure they get out of them, but there are more advantages in it like encapsulation and inheritance.
If you browse around in webmasterworld, you will find previous discussions on Object Oriented Programming, and how people use it. But in today's world, small and big projects are done using procedural and OOP ways, and there is nothing wrong with either.
I also make objects of the same type (for instance, a MySQL handling object and Microsoft SQL Server handling object) use the same method and member names as far as is possible. This makes it possible to do what would otherwise be quite a chore--that is, switching between entire database types on the fly, simply by changing a variable in my code to point to an instance of a MSSQL object instead of a MySQL object.
I've gone to the point that even for small projects, wherever possible, I use objects. They're more portable than procedural code, in my experience (though please, PLEASE do not attempt to write them for PHP4! Its OOP model is a piece of junk) and allow you to more easily handle such things as keeping multiple database connections to different servers open simultaneously (just as an example).
Obviously due to the nature of PHP, all code written will be in some way, shape, or form procedural--there's no way around that. However, take this example:
You own and operate a dog breeder's website. You need to get information about, say, 5 dogs from a database.
You could either create a Dog class, containing members such as HairLength, HairColor, Height, MuzzleLength, TailLength, WillEatStrangers.... and make a constructor that takes an argument such as the dog's name, so that your initial call would look something like this:
$Tippy = new Dog( "Tippy" );
Then simply use $Tippy->HairLength, $Tippy->Height, $Tippy->WillEatStrangers, etc. If somehow one of these values wasn't set, the variable will simply contain null, and all will be well in the world--the script will continue execution normally.
Or you could create a function that would load everything into a large array and store it in $Tippy, then access it using $Tippy["WillEatStrangers"] (2 characters longer to type! ;) and hope that that array piece is actually set for this particular dog, or else you'll be filling up your error log with notices of undefined array indexes.
You could do it either way, but from a theoretical standpoint, it's simply "cleaner" to use objects. Since an object encapsulates all of its data and member functions, you can have the same "Query()" method in two objects, making them interchangeable, even though the methods may be doing entirely different things. However, if you write two Query() functions in a procedural script, you'll have to place them in separate files and make sure that only one of them is ever used at any given time.
So you take your script to look after sessions that has a function to start, end, regenerate, destroy, log in, log out and maybe a few others and instead of having $logged_in within your start function then global $logged_in in every other function you have $this->logged_in within your class and use it in every function.
$Tippy->WillEatStrangers
What is the point in objects if the same can be accomplished using functions?
There probably isn't one for your application.
If it's obvious, use OOP. If it isn't, don't.
There are pro's and cons of each - the greatest downside of OOP is that a lot of people that use it don't understand it, and there's nothing harder to read and debug than bad OOP code.
One is not better than the other, they're just different and appropriate in different situations.
TJ
One is not better than the other, they're just different and appropriate in different situations
Nothing beats OOP when designing a CMS/template system
But using OOP for ex: just to call a few queries is a waste of time
(it’s often done due to the number of tutorials using db conn as demo)
eg
1 get input from form
2 do somthing to data
3 return results
oo works best when you are doing GUI's where say a window has a height, width x, y and z position's) its also harder to read and get to grips with quickly if you have to pick up someones code - OO freaks think "i've listed the methods I dont need any documentation"
Most web stuff doesnt have this you would be better served in most web aps in using well developed and documented procedural code + 3 tier designs with sprocs doing most of the work in the database which is where you should do your database abstraction.
