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 .
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.
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