I've been curious about what tangible benefits Object Oriented Programming offers over normal procedural programming [for some unknown but competent programmer], since everyone seems to rave about it.

From what I understand, OOP basically expands upon the idea of a class that's effectively a general classification of objects. To create objects, you instantiate them from their classes. This is actually very similar to a problem I solved in Khavi where multiple threads have to be created that are very similar to each other. However, since Khavi is written in a procedural language (ASM), I couldn't just instantiate from a class. My solution (which took remarkably little code) was just to treat the initial primary thread as an array of bytes and do a simple array copy to another location in RAM.

As for objects, I don't see why they're any different than subroutines with argument passing. You pass the arguments to the methods, which operate on them and change the state of the object, precisely as subroutines do to the program state in procedural programming. This also brings up the point of data encapsulation, which I honestly can't fathom a reason for as long as the programmer is competent enough to properly debug their code (or not do stupid things like arbitrarily change the arguments the function requires).

Another argument I see for OOP is code re-usability, which touches on several things, most notably inheritance. Inheritance can be fully implemented in any reasonable procedural language with a simple subroutine call or copy and paste. A subroutine call doesn't take much more code than a declaration of inheritance. However, if you want to re-use code across different projects, it would seem that classes are good as black boxes, right? If you think about it for a minute, the most widely re-used code in existence, the C standard library, is entirely procedural. It's also incredibly simple to use, effective, and a nice black box to most programmers.

Packages are another story. What benefit is there to using hundreds of classes over using subroutines or subprograms? Almost every operating system ever written has a library of some sort. That's represented procedurally and yet people maintain operating systems for years. Same for pretty much every library.

"Self Documenting code:" My general view on self-documenting code is that when you go to maintain it in ten years, it won't seem so self-documenting. Use comments. They're there for a reason.

"Maintainability:" If your code is well written, maintenance should be relatively straightforward.


So, can anyone try to explain what benefits there are to OOP? I feel like I must be missing something if so many people rave about it (And it's taught in every software school).

It is possible to do everything that can be done in OOP with procedural programming, but that is not where the benefits come in.

Let's say, for instance, that you are working with a large group of people on a very large project, and that each person is assigned a different part of the code. Abstraction through OOP makes it so that each programmer does not need to know the specifics of how everything works. Rather, everything is simplified so that only what is required can be seen, making the code much less of a hassle to understand.
Also, classes are excellent organizational tools. For example, I find them very useful for making enemies in games.

In short, OOP provides no functional benefits, but organizational.

@Ben: I don't think anyone is going to argue that Java (OO) is easier than TI-BASIC (Procedural). Ease of understanding really depends more on the language's syntax than the paradigm.

If I may chime in, it would be a nightmare to write any really large project in TI-BASIC.

EDIT: @tloz: I understand that class are organizational, but how are they better in that aspect from subroutines with documented variable use?

Like I said, there are no functional benefits over procedural programming. But, having worked with both documented subroutines and classes before, classes are far superior. The layers of abstraction they provide keep the code organized and manageable.

With large projects, OOP is much easyer to find the piece of code you should work at becouse you can store the classes in different folders so you won't have to spend 70% of your time by scrollingto the code you want to edit.

I'm working at a large project with java, and it has got a total of abouth 15000 lines of code, but becouse they are arranged in five different classes, the files only have got an average of 300 lines. This is much easyer to find the code you need

I've only coded in Python and HTML, and HTML really isn't much of a programming language, but I think OOP can just get in the way of things and even make a project harder.

Yes, Python is OOP.

With large projects, OOP is much easyer to find the piece of code you should work at becouse you can store the classes in different folders so you won't have to spend 70% of your time by scrollingto the code you want to edit.

I'm working at a large project with java, and it has got a total of abouth 1500 lines of code, but becouse they are arranged in five different classes, the files only have got an average of 300 lines. This is much easyer to find the code you need

Khavi, the project I mentioned in my first post, as approximately 4000 lines of code at the moment*. The code is currently divided into 3 subprograms and it takes me around 15 seconds to find the code I'm looking for. I'm not sure that putting

public static void main()
{
      Something
}

 significantly improves your code's organization above "#include <file.s>" or ".macro"

*I assume you meant 1500 lines of code, not 15000, because 300*5= 1500.

I'm not asking whether procedural programming or OOP is better, I'm asking what the benefits of OOP are over procedural programming. Procedural methods aren't perfect. For example, networking in most procedural languages is a PITA because of all the things you have to deal with. There are languages that make networking relatively easy though, like Java. I think tloz128 brought up a good point with the part about working with other programmers. It's much easier to just pass arguments than read the documentation for that routine.

Quote from: Qwerty.55 on June 23, 2011, 06:45:23 pm

*I assume you meant 1500 lines of code, not 15000, because 300*5= 1500.

no, I actually forgot a 0 at the 300. that should be 3000

You rarely have a fully working engine and world in 1500 lines, especially in 3D games.

Depends on the language and the desired realism. You can certainly do a decent game engine in 1500 lines with the right language.