OOP is undoubtedly one of the most complex programming techniques to explain. In fact, it's not so much a 'technique' rather than a whole new method of looking at programming itself. There are entire books on the subject, and it's well beyond the scope of this article to introduce you to every philosophy and implication of OOP. To understand OOP, you must first understand what programming was like before OOP.
Back then, the basic definition of programming was this : a program is a sequence of logical instructions followed by the computer. And that's it. All well and good, but let's face it, it's hardly inspiring. Until now, that is. It's been hiding in the background for quite some time now, but OOP has finally taken off. In an OOP programming language, the emphasis is placed far more on the data, or the 'objects' used and how the programmer manipulates them. Before OOP, numbers were simply an address in memory; a sequence of bytes that meant nothing. Now, however, through OOP they have become far more than that. The program is now a solution to whatever problem it is you have, but now it is done in the terms of the objects that define that problem, and using functions that work with those objects. Confused? Don't worry, you won't need to understand OOP to use it within your programs. Indeed, the best way to learn what OOP
Object-oriented programming solves some of the problems just mentioned. In contrast to the other techniques, we now have a web of interacting objects, each house-keeping its own state
Object-oriented programming. Objects of the program interact by sending messages to each other.
Consider the multiple lists example again. The problem here with modular programming is, that you must explicitly create and destroy your list handles. Then you use the procedures of the module to modify each of your handles.
In contrast to that, in object-oriented programming we would have as many list objects as needed. Instead of calling a procedure which we must provide with the correct list handle, we would directly send a message to the list object in question. Roughly speaking, each object implements its own module allowing for example many lists to coexist.
Each object is responsible to initialize and destroy itself correctly. Consequently, there is no longer the need to explicitly call a creation or termination procedure.