Thread: Is OOP better
View Single Post
  #5  
Old 09-01-2015, 09:47 PM
Hall of Famer's Avatar
Hall of Famer Hall of Famer is offline
Administrator, Lead Coder
 
Join Date: Dec 2008
Location: South Brunswick
Posts: 4,448
Gender: Male
Credits: 327,646
Hall of Famer is on a distinguished road
Default

@ Kessstryl:
I am not worried, I was just stating what I think is true. And as I said, the old rusnak script was coded in procedural style for a reason, and the mysidia script needs to be in OOP also for a reason. If you are writing your own project, and procedural style suits your need, its perfectly fine. Sometimes it may even be necessary, for instance you are a freelancer working with a client trying to get some working code the next day. The bottom-line is, to write code that works, and works best for your project.

@ Kyttias:
You bring up an interesting point. I'd say there are three criteria you can check if you want to go for the procedural or OO approach:

1. Is your application a large or small scale project?
2. Will you be developing your application alone, or to work in a dev team?
3. Do you develop and launch your project once for good, or will it be continuous development/integration over months or even years?

If your project is small, you work alone, and you are sure that your project will not have many new features to be added with time, then procedural may suit you. A good example is a homework assignment for a web development class, if your instructor only cares about getting the work done, and that you have severely limited time to complete it. After all, you meet demanding clients all the time, they ask for different things. If you choose to work with them, you have to abide to their specified rules. In older programming languages like C and Fortran, OOP may not even be an option.

However, in most cases you dont know how your project will grow into, several months from now. You may have planned it to be a small application, but become ambitious later. If you start with procedural paradigm, changing into OOP is very hard, and you may very well have to rewrite from scratch after struggling with refactoring for a long time. Just like what I did when I first took over the adoptables script from BMR. Initially I only meant to maintain it and add some minor new features, but with time I became more ambitious and I decided to add a lot more user-requested features such as breeding, itemshop, etc. Because Rusnak Adoptables was originally written in procedural style, I found that development became increasing harder with each new feature I added. With OOP, its supposed to be the opposite, with initial development overhead but much less future development time/cost.

I agree that OOP can be serious overkill for small project, the complexity it introduced is unnecessary for these projects. But I disagree with the performance point you brought up, although OOP is slower than procedural in general, its very unlikely to slow down your site. The example in your link itself is flawed, because it's not using OOP the right way. So instead of this:

PHP Code:
for ($i=0$i<1000000$i++){
     
$testclass = new test();
     
$cnt += $testclass->one(); 

You should do it the other way instead:

PHP Code:
$test = new test();
for (
$i=0$i<1000000$i++){
    
$cnt += $testclass->one();                 

From benchmark test on my own server(averaged over 10 runs for each test), the 'procedural style' took 0.142s, the 'old OO style' took 0.315s, and the 'new OO style' took 0.166s. As you see, OOP is not significantly slow compared to procedural programming, it's roughly 15-30% slower if you do it right. Also in medium to large sized applications, the database hits are usually where the benchmark truly is, and the overhead of using OOP is almost negligible. In such cases, you wont need to do 'micro-optimization' with OO code, since it wont affect performance much. To conclude, the example in your link is bad because it exaggerates OOP's performance overhead, due to it's improper use of OOP.

Now it's the revelation time, the truth is that, you have a misunderstanding of what OOP truly is. OOP is more of an approach, and a way of thinking, it's not just about the OO syntax. The OOP benchmark example in the link you find, it's not true OOP, its procedural in disguise. Just by creating a 'test' object and call its method, does not make it OOP. Instead, you may be doing OOP without using the OO syntax. You may be surprised by this idea, but its a revelation I found out about 2 years ago, it was eye-opening. You may want to read this article below to learn what is true OOP, and what it differs from procedural code using objects:
http://blog.ircmaxell.com/2012/07/oo...ural-code.html

So what is the true OO way to write the benchmark test, it is this:

PHP Code:
class test{
    function 
runCnt($iter) {        

        for (
$i=0$i<$iter$i++){

            
$cnt += 1

        }
        return 
$cnt;
            
     }

}

$test = new test();
$cnt $test->runCnt(1000000); 
As you see, in the true OO example, the client code has only two lines, and it is unaware of the internal implementation of method test::runCnt($iter). This logic(mostly a loop) has been abstracted and encapsulated away from the user of the test object. As a client coder, you know there is a test object and it can return $cnt based on the number of iteration, and thats all you need to know. You may say that what is inside the method is still procedural, I wont say no, it clearly is procedural syntax inside the test::runCnt($iter). However, I am still doing OOP, because I am thinking in OOP now. The way I abstract away the implementation of cnt increment, it is OO.

Of course, abstraction has to stop at somewhere, when it no longer makes sense to encapsulate your logic, there's no need to do this. It wont make your code more like OOP, and it only incurs performance penalties. Note that whats most important about OOP is the second letter 'O'(oriented), not the first letter 'O'(object). You will understand what I mean one day, and this is when OOP truly clicks with you. I had the same confusion as you do years ago, I was also not buying into the power of OOP, but everything has changed.

For smaller projects, especially if you are sure it aint likely to grow, procedural style will suit your need. I never deny it, as I pointed out that rusnak adoptables(the predecessor) was coded in procedural style and it worked fine. But when BMR coded rusnak adoptable, he meant it to be a part of his learning of web development. He had planned it to be small, lightweight, and not to grow in future. But once it became mysidia adoptables, it's a different story, I actively developed the script and kept pushing new features to the product. At times like this, it is when procedural style was giving me all kinds of headache, its hard and impossible to maintain and extend properly.

The reason why I heavily advocate on OO is that, in real life applications, procedural programming will hardly suit your need, because we mostly tend to end up with ever-growing projects. Even if you work with a client as freelancer, you will need to consider that the same client may return with more and more requests. If you have done the procedural way, it may get him a working application quicker, but then once he keeps nagging you for future improvement, you will realize it becomes harder each time, and eventually impossible.
__________________


Mysidia Adoptables, a free and ever-improving script for aspiring adoptables/pets site.
Reply With Quote