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

OOP is way better.

OOP is useful when you are working on large projects, and when you are working on a program with other people. Then, those other people don't really have to know a lot about your code, since OOP abstracts that away from them. They can focus on what's more important, writing their code instead of trying to understand your code.

Objects are a necessity regardless of language. You need some way to group primitives together. You can either have the language support that, or you can fake it with all sorts of hacks.

Proper support > hacks, simple as that.

Consider gtk_button_set_label(mButton, "something") vs. mButton->setLabel("something"). The procedural version is more verbose for no reason. It is also highly dependent on the type whereas the OOP version is not (I could change mButton to be a checkbox, for example, without needing to go through and update every place it is used)



Data encapsulation has nothing to do with OOP vs. procedural. C can do data encapsulation as well - it just means keeping your private stuff private (which you should always do - it has nothing to do with not being "stupid" or "properly debugging", it is just better design)



copy/paste is not inheritance and is a *HORRENDOUS* practice. If you ever copy/paste code from one function to another, your design is broken.



This is not an OOP vs. procedural thing. Code re-use is good regardless of your design strategy.



Uh... what? The API for a kernel is very, very small. The libraries that ship with OSes are sometimes procedural, sometimes not (for example, .NET and Java obviously are not - neither is QT, or most of the KDE libraries).

Namespaces/packages are brilliant, languages without them are hell.



If you honestly don't get why objects are a good idea, you have never worked on a real project. There is a reason even procedural languages try to fake having objects (in C this is done by storing function pointers inside of a struct, for example)

I am too lazy to actually make my own post so instead I quote people and then don't say anything new

Why OOP is a nice way to think: http://en.wikipedia.org/wiki/Message_passing


A thousand times this. Qwerty, have you ever worked on real code in your life?


Not too mention Cocoa. You know...that thing at the heart of the iPhone, iPad, iPod Touch, Apple TV, and every Mac computer made in the last decade.

It depends on what you're doing, to be honest. Granted, for most things, copy/paste probably incurs a ton of bugs.

As for real code, I must say I have never had that displeasure. It's clearly evident

No, it isn't. Duplicate code always indicates that refactoring is needed.



displeasure? Not at all - at least not with OOP

EDIT: And for what it's worth, even the C standard library has hints of OOP design. fopen returns a file "object", for example, which is a pseudo interface as you can use fprintf to write to "streams" that can be files, sockets, or other forms of I/O such as the console. A character array is also considered a string (an "object" per se), with a set of methods dedicated to it.

Like Kllrnohj mentioned, the C standard library is partly object-oriented, especially with regards to file handling.

I've had the "pleasure" of diving into the Unix V6 and V7 kernel source code (from the mid to late 70's) and I've come to realize that even those old pieces of software were object-oriented. Take the file handling for example (a different beast from C's fopen() et al). Each process stores an array of pointers (or "references") to file objects. Every time a process wants to read from a file, the system calls the file's read function ("method") depending on the type of file (regular file, pipe, socket). So in a sense, V6/V7 even demonstrate polymorphism. The way those old kernels implemented this was kind of clunky (basically an "if (file->type == FPIPE) readp(file) else if (file->type == FREG) readi(file)"). Other places in the kernel use the "type" field as an index into an array of pointers to functions, such as for reading from character devices (eg, "cdevsw[MAJOR(dev)].d_read(dev)", which uses the device type as an index into the cdevsw array, which contains read/write/other methods).

The Linux kernel uses yet another approach: use function pointers in the structures themselves (or rather, a single pointer to a structure that contains pointers to method functions). Eg, "file->f_op->fop_read(file, ...)". These pointers are initialized when the file is opened, which is basically saying the open method is the constructor for the file class.

Last, you mentioned your project "Khavi". Guess what? It sounds like it is also (somewhat) object-oriented. It (almost) doesn't matter what language you use; you can write OO programs in practically any language, assembly language included.

As you should hopefully see, object-oriented programming has been around for a long time to various degrees. It's just that the lessons learned from using older languages like C, which don't have OOP syntax features, have influenced the designs of languages that do have OOP syntax features. OOP is nothing to be afraid of or to disdain or to avoid. You may want to avoid some specific languages that have OOP syntax features, but not OOP itself. Also, just ignore the hype surrounding OOP, which I thought died along with the dot-com bubble.

(I know my post is long enough already, but apparently I'm in rant mode...)

On the flip-side, you don't need OOP for everything. Not everything can be classified well if at all. For example, pure mathematical functions. Java and other similar languages have a Math class to contain those functions, but they don't really benefit from being in a class. They are all static functions since instantiating a Math object doesn't make much sense, and it wouldn't improve the design of a program any. Java puts them all in a class only because it can't have functions outside of a class (whereas C++ can, being compatible with C).

OOP is really just a technique, and so is procedural programming. OOP emphasizes the organization of a program's data, whereas procedural programming emphasises the organization of its procedure calls. OOP is built upon procedural programming, since having a program with only classes and no methods is kind of pointless. Use these and other techniques (eg, functional programming) as they are needed in each situation. You can generally use many techniques in most common languages, so don't limit yourself to one technique.