PHP OO Vs simple procedural coding
Moderator: General Moderators
PHP OO Vs simple procedural coding
Hi,
I thought of shifting my code to OO in php. But recently I read an article which talks about advantages and disadvantages on using OO. http://php.weblogs.com/discuss/msgReader$535?mode=day
Now I am confuesed as to should I go for OO or keep the code as standard procedural PHP without using OO. I am not much awre of OO. Please PHP experts, suggest .
I thought of shifting my code to OO in php. But recently I read an article which talks about advantages and disadvantages on using OO. http://php.weblogs.com/discuss/msgReader$535?mode=day
Now I am confuesed as to should I go for OO or keep the code as standard procedural PHP without using OO. I am not much awre of OO. Please PHP experts, suggest .
There's a thread in the advanced forum about this: viewtopic.php?t=11048
The comments in the thread you posted about OOP being 2 - 3 times slower than other methods don't really square with my own experience. It's perfectly possible to write fast scripts with OOP.
The eclipse library http://www.students.cs.uu.nl/people/voo ... /index.php
is maybe one of the best examples of good OOP design in php.
The more complex your php program is, the more likely it is you'll benefit from using OOP.
The comments in the thread you posted about OOP being 2 - 3 times slower than other methods don't really square with my own experience. It's perfectly possible to write fast scripts with OOP.
The eclipse library http://www.students.cs.uu.nl/people/voo ... /index.php
is maybe one of the best examples of good OOP design in php.
The more complex your php program is, the more likely it is you'll benefit from using OOP.
Thank you very much for the reply. For my application, I don't really know whether I need to use classes.
Basically, I am developing a webpage for our synchroton beamline.
the application has 3 main modules.
1. Users
2.Reviewers
3. Administrator
Users can register and submit their proposals (for the synchroton beamline...research organization), scheduel their experiments.
Reviewers can review the proposals (who should also have an account in our webpage) nad give their review comments. they will be able to view proposals reviewed by them etc.,
Administraotrs should be able to manage the news, events, schedules, manage user's , reviewers, proposals etc.,
So, for these should I be using classes or functions? There will be some functions which should be accessed by all 3 modules.
Please suggest
Basically, I am developing a webpage for our synchroton beamline.
the application has 3 main modules.
1. Users
2.Reviewers
3. Administrator
Users can register and submit their proposals (for the synchroton beamline...research organization), scheduel their experiments.
Reviewers can review the proposals (who should also have an account in our webpage) nad give their review comments. they will be able to view proposals reviewed by them etc.,
Administraotrs should be able to manage the news, events, schedules, manage user's , reviewers, proposals etc.,
So, for these should I be using classes or functions? There will be some functions which should be accessed by all 3 modules.
Please suggest
veenasv: Asking whether or not to use Procedural or OO is like asking whether someone should use a Hummer or a Corvette. Each has its use.
My question is whether the PHP application needs to be ultra fast. If it doesn, you will probably just want to write the business logic in C, as a PHP extension.
The benefits of properly crafted OO, IMO, out weigh the disadvantages it brings.
However, the disadvantages of improperly crafted OO do not.
My question is whether the PHP application needs to be ultra fast. If it doesn, you will probably just want to write the business logic in C, as a PHP extension.
The benefits of properly crafted OO, IMO, out weigh the disadvantages it brings.
However, the disadvantages of improperly crafted OO do not.
- greenhorn666
- Forum Commoner
- Posts: 87
- Joined: Thu Aug 14, 2003 7:14 am
- Location: Brussels, Belgium
IMHO, OO has the advantage to produce more reusable and easier to maintain code over good ol' procedural.
Data Encapsulation is really great... Took me years to understand this, but now that I'm used to it, I would never go back!
Again, as jason said, modelling is real important too, but that is in procedural too... Your code might end up running faster with improper procedures than with improper classes. But your procedures will end up far more messed up over time than your classes probably will. So that speed wont be quite a difference after a while anyhow (speaking of improper code), but at least OO will be far more maintainable...
Speaking of which, if you decide to go for OO, you might want to read about the MVC (Model-View-Controller) paradigm, will save you lot of time and hasle!
Data Encapsulation is really great... Took me years to understand this, but now that I'm used to it, I would never go back!
Again, as jason said, modelling is real important too, but that is in procedural too... Your code might end up running faster with improper procedures than with improper classes. But your procedures will end up far more messed up over time than your classes probably will. So that speed wont be quite a difference after a while anyhow (speaking of improper code), but at least OO will be far more maintainable...
Speaking of which, if you decide to go for OO, you might want to read about the MVC (Model-View-Controller) paradigm, will save you lot of time and hasle!
Re: PHP OO Vs simple procedural coding
I've read that as well as the other post on that page titled "Some rough benchmarks: ban $this" which I think is required reading for a dedicated OOP'ers.veenasv wrote:Hi,
I thought of shifting my code to OO in php. But recently I read an article which talks about advantages and disadvantages on using OO. http://php.weblogs.com/discuss/msgReader$535?mode=day
Now I am confuesed as to should I go for OO or keep the code as standard procedural PHP without using OO. I am not much awre of OO. Please PHP experts, suggest .
The skinny on this is simple. For most projects of small to moderate size (and I say even large ones), one could do fine without using objects proper (there is a reason I say it that way).
As for performance, 2-3 times slower may be a bit much, but it is slower. Look up the benchmarks that John Lim has done comparing some of the major user land db abstraction layers. You'll see that there is around 30% additional overhead for the fastest of the test libs, which was Adob.
http://php.weblogs.com/discuss/msgReader$1112
So, by removing the db abstaction layer, you can realize at 30% gain in performance? First off, why would you want to do that? However, who says the abstraction layer has to be object based?
The reason I'll even bother to state this is becuase database access will become the bottleneck in the system extremely fast. Ask Yahoo and Slashdot! That's an eventuality that I'm planning for where I work. Move the db's on to their own gigabit network is step one. Step two is to load balance read operations amongst the pool of replicated slaves.
That said, why not take a different approach up front? Objects are not required for clean and easy to maintian code bases. As I said in another post, I've been chewing away at the code for the QIII engine which is written in C. It has no objects proper, yet it's a great hunk of code that is well modularized and easy to extend.
Another thing I'll say for large user land libs like that is that you are going to take a big hit up front just parsing the libs. Use an accellerator if you have an option, which many people don't. One of the chaps on the PHP-DEV list sent me an email stating that parsing one of those big libs accounted for 1/3 of the scripts execution! That's why I think Eclipse is so much better for what most of us are doing as it doesn't include tons of functionality that we don't often use. And even more importantly, there isn't a ton of required stuff upfront just to get a record out of a db? (*cough, PEAR, phlegm, gurgle gurgle...).
Really, what I'm saying is that key portions of code in some cases should be given design considerations based on what they are responsible for. After that, write it in C!
What I like to do, which is sure to get me flamed here, but oh well, is use method less objects like structs from C, then just perform operations against the elements of the objects directly. Those operations / functions are specifically to deal with those method less objects. It's like the idea of an object with the methods on the outside. This way, I still get encapsulation (not to be confused with data hiding) of related bits of datum, a high level of abstraction, and 0% overhead compared to taking an object based approach. It's an object based approach at the conceptualization level, but not at the implementation level.
Anyways, it's OK to not use Objects. Objects are cool, but the main drawback is that performance hit. The second is code bloat from poorly writen, 'let's throw in the kitchen sink frameworks'. Objects have their place, but reuse, maintainability, extendability, modularity, and ease of development can be realized in a procedural approach as well.
Just honestly consider what it is you are doing and let the result (of such considerations that is) guide you.
Cheers,
BDKR
Re: PHP OO Vs simple procedural coding
So, the object is merely a data store kind of like an array?BDKR wrote: What I like to do, which is sure to get me flamed here, but oh well, is use method less objects like structs from C, then just perform operations against the elements of the objects directly. Those operations / functions are specifically to deal with those method less objects. It's like the idea of an object with the methods on the outside. This way, I still get encapsulation (not to be confused with data hiding) of related bits of datum, a high level of abstraction, and 0% overhead compared to taking an object based approach. It's an object based approach at the conceptualization level, but not at the implementation level.
Re: PHP OO Vs simple procedural coding
Yes and no. Some say it is. Some say not. It's my understanding that this was a topic of dispute in some circles for some time.McGruff wrote: So, the object is merely a data store kind of like an array?
But let's think about this. Shouldn't an object store data that is only pertinent to it's (the object) intended mission? That said, I don't believe that an object is merely a data store.
The very concept of what OO is should prove this. In the purest sense, OO is like environment simulation. An object being an object in that simulated environment. That object, being independent and nearly autonomous will have all the data (and should have nothing else) and of course, behaviours (methods) it needs to carry out requests or respond to changes in the environment.
That doesn't sound like a data store to me.
Ultimately, eventhough I put the methods outside of the object, I still consider it an object.
Cheers,
BDKR