What's the difference between a procedural program and an object oriented program? [closed]

Question

In a procedural program, the code is king and the data is subordinate. In other words, you have programs which act on data and they're not usually tightly bound.

In the OO world, objects are the primary thing of interest. An object consists of data and the code that is allowed to act on that data, and they are very tightly bound. It is the concept of encapsulation, the hiding of information.

An example, let's say you have a number and you want to double it. A procedural way of doing this is:

n = n * 2

The code here quite explicitly multiplies n by 2 and stores the result back into n.

The OO way of doing this is to send a "message" to the number object telling it to double itself:

n.double();

The advantage of this is called polymorphism. What happens when you decide you want to be able to double a string like "bob". In the procedural world, you'd have to provide more code to do the doubling but you'd also have to call that code differently.

With OO, you create a string object which can also take the 'double' message. The code to double a string belongs to the string object so it knows it has to act differently to the number object. If it decided that "bob" * 2 was "bobbob", the code would look something like:

class number:                    class string:
    int n                           char array s
    procedure double:               procedure double:
        n = n * 2                       s = string_join(s,s)

Then you could call x.double() no matter what actual type x was (number or string) and it would know which code to run - this greatly simplifies your code. You can double integer, strings, matrices, complex numbers, reals, window sizes on your monitor and all sorts of different things.

And you're right, a C library can be made to look a little bit like objects. The classic example is stdio.h - you don't ever care what a FILE* actually points to, just the fact that it will behave in a certain way. The FILE*, fopen(), fclose() and other functions are an class of sorts representing the I/O capabilities of C.

You can program procedurally in most OO languages, but the power of OO comes from the ability to inherit, encapsulate and abstract that procedural logic. I think you are correct, a library should look a lot like a class. It should have its own scope and encapsulate logic behind functions with meaningful names.

You are correct in your observation that object-oriented programs are based in many ways on the procedural paradigm. You are also correct in that syntactically all that really happens is that you invoke functions. In fact, you could implement many features of object oriented languages using procedural mechanisms (e.g., function pointers in C++). You could thus do an object-oriented design and still implement it in a procedural language (e.g., like old C++ compilers did).

The importance of the object oriented paradigm is not as much in the language mechanism as it is in the thinking and design process. In procedural programming the thinking is about operations and breaking those operations down using other operations, grouping them into modules, etc. This means that the data or state falls into a secondary importance. It is like thinking of mathematical operations.

The object oriented paradigm, on the other hand, says that you need to think of state and operations together as an entity, and then design your program as interactions between entities that exchange state and activate operations.

The difference between the two is subtle but significant.

In a procedural program, modules interact by reading and writing state that is stored in shared data structures.

In an object oriented program, modules in the form of objects interact by sending messages to other objects.

IMHO, object oriented programming is a concept that exists at a higher level of abstraction than procedural programming. The two are not mutually exclusive in that individual methods in an OO program look pretty much the same as individual functions in a procedural program. This contrasts with, for example, functional programming, which requires a completely different mindset. Furthermore, you can write procedurally in an OO language by making everything static, etc. You can be a human compiler and write effectively OO code in C by using lots of function pointers and struct pointer casting.

OO, then, is more of a design philosophy and world view than something w/ a rigorous definition. It requires that inheritance, polymorphism, etc. be used as major patterns in structuring your code, and that syntax be provided to make these expressible without resorting to low-level tricks. It requires that you think of code that acts on the state of a collection of data as being a property of the data, not a procedure that exists by itself. It is not black and white. Your code can be "more" or "less" OO depending on how heavily you rely on inheritance, polymorphism, classes and the "methods as a property of data" worldview as a means of structuring and explaining/understanding your code.