In order to understand what object oriented programming, what it is and how it differs from non-object oriented programming we first need to understand what non-object oriented programming is.
One problem in doing this is that it is easy to forget that a non-object oriented programming language is not defined as lacking object oriented features — rather object oriented programming languages are identified as such by having certain features. I will (because it makes my life easier) define both at the same time.
Defining object oriented programming is easier than defining it’s opposite — this is a lot like taking a look at a void and trying to define the size of it. It just doesn’t fit in my mind.
An object oriented programming language is a programming language which allows the programmer to define functions and data types in such a way that they can be reused without changing the program, with types and functions that didn’t exist in the program when the program was written.
This is essentially the keyword template in C++ or generic in Java, the idea of polymorphism and inheritance, and finally function overloading. Haskell supports this by defining arguments to functions as being (essentially) unknown or by making data types which are pseudonyms for more than one other datatype (again, essentially).
Object orientation is not about being procedural — in fact, you will find more languages that are not procedural that supports the key features of OOP. Haskell is one, Lisp another — both of these are functional programming languages.
Then what is a non-object oriented programming language? Well simply put, that’s a programming language which does not support the concept of a template or generic or does not allow the programmer to overload functions of any type.
Other people will have other definitions of object oriented programming, but this one seems to be the most common and the same features seems to be omnipresent in definitions of object oriented programming. Personally I see these features as the most important differences from C to C++ — C doesn’t support any of these things at all, but C++ does.
The question is then, what do we need OOP for?
The common programmer will see little use for it, until they want to use the same algorithm on several different data types. If the programming language he is writing his software in is not object oriented, he will have to copy all the code over and over again and all of a sudden, his code bloats and the maintenance cost of anything involving that code grows every time a new datatype is supported. This makes it harder for the programmer to do any real work.
Of course, you’ll think that most projects don’t use the same algorithm over and over again, but that’s just not true. A lot of projects have to sort a lot of things, for instance. Everything that needs sorting, has to have it’s own code if OO is not supported.
OO is of more use to people who want to write libraries though — end user programmes gain little to nothing from OO in the long run. System libraries are likely to gain a lot more from OO than non-OO, since they can implement algorithms that work on any datatype whereas non-OO have to provide the code itself and the user will then have to modify and recompile the code.
OO is not the holy grail — it doesn’t reduce expected executable size in most cases (Java is different, but that’s about all I know), it doesn’t make your programmes run faster (mostly) and it doesn’t allow you to avoid classes of bugs (but it can, some times, make fixing bugs easier) — if a language supports a feature and you abuse that feature, it doesn’t matter if it supports OO.
Having said all of that, I don’t think you should ever say “Language A is an object oriented language”, regardless of whether or not it supports generic programming or code reuse — most languages simply support object oriented programming, they are not in themselves object oriented (which is something else).
