Is OOP better

[Kesstryl]

This is simply a discussion thread. This is not a commentary on Mysidia moving to OOP PHP. I'm more interested in opinions as I also program my own games.

Procedural PHP is fairly easy and has a logical progression that one can see immediately. Almost anyone who can utilize logic can pick it up. The pro for procedural, besides being fairly easy, is that it can also make the program run fairly quick (not a huge performance increase, but still there nontheless). The major con is the mess one can easily make in stringing a bunch of procedural ifs/elseifs/cases/switches along with repeating a lot of code (unless one is proficient with making functions).

OOP is a lot harder to pick up (I have not yet done so successfully, it's not that I can't, it's just that I have to keep backing in and out of pages to see the logical progression of what's going on, not fun). It's like learning algebra when procedural is basic arithmetic. That's the major con. It keeps only the elite programmers in, and the rest of the casual/hobbyists kind of out. The pro is having neat looking (easy for other OOP programmers to use) and re-usable code (although I argue that one can make re-usable code with functions).

Things like security, modern look, MVC, re-usability, all this can be done with procedural code. So why is procedural looked down on as being so dirty?

[Hall of Famer]

Yes OOP is better, and better by every aspect once you get a hang of it. The truth for most programmer is that, the moment they fully understand OOP, they will be reluctant to code in procedural style any longer. OOP makes code much more organized, modular, extensible and reusable.

OOP is indeed somewhat harder than procedural programming, since it requires a totally different way of thinking, but a very humanized way of thinking. Instead of worrying about how to instruct machines to do work for you in procedural style, OOP focuses more on each object/entity it interacts. So take a step back from how to get the program to execute a series of code, just start to model basic entities such as User, Adoptable, Item, etc. What is a user, what can an adoptable do, how do users, adoptables, and all kinds of entities interact with each other? If you can model your objects in this way, it will be easier for you to learn and appreciate OOP. Id say part of the difficulty in learning OOP is a direct result of the books/online-tutorials failing to teach beginners OOP in the right way.

Procedural programming is looked down as dirty because it is not by definitions scalable. With BMR's rusnak adoptables, procedural programming works about fine, but once I took over and started to add features and features on it, I found it became increasingly challenging to get things to work, and bugs may arise from nowhere. With OOP, it will be a lot easier to add new features and improve upon an existing script, given that you know how to write the appropriate code.

A fair comparison of procedural and OO programming is high school diploma and college degree. Procedural code is like high school diploma, enough to get you started with a basic job, but will place serious limitation on how far you can reach. OO code is like college or graduate level degree, its harder to get started and take longer to learn, but will help out in a long run once you are in the job market. Hope you understand the analogy here.

Mysidia Adoptables is moving towards OO because its gradually turning into a medium to large sized application. It's not the old Rusnak era anymore, with the way new features have come along. Doing OOP means that I have to spend a lot of time upfront before the new script is released, but once it's ready I will find it a lot easier and faster to implement new features. It's a tradeoff between initial development cost and continuous development cost, but in a long run OOP will pay off.

[Kyttias]

And yet, I can easily argue that OOP is overkill for small to medium projects and takes up more lines of code to put functions into classes that will only ever be called once and don't really need to be a function, anyway.

While "redundant" coding may be typing the same thing up multiple times, there's also the folly of putting non-redundant code into a class file and then forcing it to be loaded every time that class is called, even though it will literally never be used in relation to that class ever again.

So if the answer to "will I ever use this function again?" is no, then, no, it doesn't belong in a class file. It'll just bog down the load times of that file. Significantly? That's arguable.

I prefer KISS logic. "Keep it simple, stupid!"

OOP is great for keeping code organized, especially when working in teams. But... there is, actually, a performance hit. If you're the only one ever going to see the code, go ahead, stay procedural! Definitely! Well-commented code is just as important.

Undocumented object oriented code is twice as much of mess as a single file that I can at least use a search function on rather than having to cross-reference multiple other files to see what messed up where. I called a class? Did I call it with the right parameters in the right order? Inside that class I called a class? Inside that class I called another class? Good lord, just WHY? I could have done it in four lines of code and instead I just loaded multiple files and wasted seconds of processing time. I don't really care about readability or even copy-pasting if it means I understand it exactly where I'm using it. I don't have to chase an error down a mile away. I don't have to guess what the function I wrote in another file does exactly, because it's all right in front of me where I'm working on it.

I prefer to limit my classes to functions that interact directly with the database and other immediate functions that assist the ones that touch the database. I see classes as a necessary evil, and not a solution to every problem. Imagine it like how the English language uses contractions. We drop a vowel, we shove some words together. Now imagine if w't'lk'dl'k'th's (we talked like this) - let's just shove all the words together and remove the vowels. You're supposed to guess what's there. That's what happens to my brain when I view object oriented code. I have to guess what's there. It's counter-productive to my productivity, even though other programmers love it.

If you're using a class inside of a class inside of a class - just - don't.

The worst part is that in the defense of "organization" (which I feel it isn't), it stabs performance by loading code it won't even run. It thinks it might, it's in the file alongside the function you called, so the rest of its all there, too. It took time to load that chunk. According to studies, it may have taken 600% longer than if you'd just written it without the spiderwebbing into classes.

If you can do it without, do it without. If you can't do without it (it NEEDS to scale), don't do without it (use objects!). But know when to draw a line (does it REALLY need to scale?). Don't do it for everything (do you know what this word scaling even means?), it IS, in fact, counterproductive. In every way - both in terms of organization and compile time. "Half your code shouldn't be OOP baggage."

/end rant

tl;dr - Sick of people defending OoP blindly.

[Kesstryl]

Hall Of Famer Don't worry, I started this off by stating that this is not a poke at Mysidia. I understand that OOP does make pages of code easier for other (OOP) programmers to follow and contribute. I do think some things might be better, just like Kytias said with using classes for database calls, something you will use over and over and over again. I know the era of procedural code is pretty much over, except in beginner coding classes or books.

However, all the things that are argued as being pro-OOP, you can have with procedural code. I know of several MVC frameworks (albeit micro and not full on ones like Codeigniter) that use pure procedural code with not one class. You can have re-usable code with the use of functions. Heck I've even seen blocks of html echoed in functions (not classes, just plain and easy to understand functions) and then included on webpages to piece together the header, footer, and navbar with a main content page. Modular, MVC, re-usable, all can be done procedurally if the code is well organized (and yes I also love commented code, comments are A++). I think Kyttias hit every peeve I've been having with OOP. When overused it does make the code so much more complicated than it needs to be. I'll get there with learning it, but sometimes I want to throw my computer out the window with it.

Kyttias thanks for the link to that page, I knew there was a performance hit with OOP, but that's a lot more than the "minimal" hit I was led to believe.

[Hall of Famer]

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

[Kesstryl]

Thanks for the reply @Hall of Famer. Those are definitely things to take into consideration. I'm sure one day it will click for me, until then my own web game is, as you pointed out, not meant to become a huge application. It will be a simple game, and if I ever decide to put it online and let people test drive, it will likely remain a small game. I wouldn't have the funds to scale up the server so it would have to stay small, and when using low cost hosting, I don't want bandwidth to force me to shut my game down if I don't have funds to upgrade the hosting for it. If one day OOP does click and I decide my game needs a facelift to expand it, then it will be small enough to work with. For now I can't hate procedural because it makes sense to me and I know exactly what my code is doing. Maybe it's the linear approach that I like, and the abstraction is just too abstract for me at this point.

[Nemesis]

OOP is the way to go.

Also Single Page Applications (SPAs) are the future.

It would be interesting to see MySidia rebuilt as an Angular (or equivalent) Application. and PHP only used to handle the data.

If only I had time for anything other than work

[Hall of Famer]

Originally Posted by Nemesis

OOP is the way to go.

Also Single Page Applications (SPAs) are the future.

It would be interesting to see MySidia rebuilt as an Angular (or equivalent) Application. and PHP only used to handle the data.

If only I had time for anything other than work

Yeah OOP is indeed the way to go, from Mys v1.4.0 onwards the script will be fully object oriented(minus third party libraries, cannot control their source code). With angular JS, unfortunately, theres no plan to use SPAs for version 1.4 and 1.5. I am still a bit skeptical on the hype of angular JS and node.JS, but I definitely am keeping an eye on it. With the introduction of class-based syntax in EMCA 6, it looks very promising. Perhaps, we will make the switch one day.

[Kesstryl]

Unless I want to pay more for my hosting, I will not be able to use Mysidia if it goes the way of using node.js. I think many of us only have basic hosting. For getting a game up and running as first time devs, I don't think we will be able to do it if we have to use a node server.

[Hall of Famer]

Originally Posted by Kesstryl

Unless I want to pay more for my hosting, I will not be able to use Mysidia if it goes the way of using node.js. I think many of us only have basic hosting. For getting a game up and running as first time devs, I don't think we will be able to do it if we have to use a node server.

Well I dont think we have discussed migrating to node.js before, I was simply saying that I aint buying the hypes of it. XD When I said perhaps we would make the switch, I was talking about angular.js, not node.js. And even this will not happen at least until version 1.6. Sorry for the confusion.

Even if in remote future we will move to something other than PHP, it is only under the condition that the new language/platform will be well supported on shared hosts. The way node.js currently stands, we will not move even if I buy the hype(which I said earlier, I dont, so you are further guaranteed). ^^