What is Object Oriented Programming (OOP)?
By Tony Marston2007-01-30
What OOP is NOT
OOP is about modeling the 'real world'
OOP is a programming paradigm that uses abstraction to create models based on the real world. It provides for better modeling of the real world by providing a much needed improvement in domain analysis and then integration with system design.Rubbish. OOP is no better at modeling the real world than any other method. Every computer program which seeks to replace a manual process is based on a conceptual software model of that process, and if the model is wrong then the software will also be wrong. The conceptual model is created as an analyst's view of the real world, and the computer software is based solely on this conceptual model. OOP does not guarantee that the model will be better, just that the implementation of that model will be different.
The term "abstraction" is also open to interpretation, and therefore mis-interpretation, as discussed in Understand what "abstraction" really means. This is why some people's abstractions look more like the work of Picasso when what is required should look like the work of Michelangelo.
That is why it is possible to create software that does A, B and C but it is useless to the customer as it does not also do X, Y and Z. The real world may contain X, Y and Z but the analyst did not include it in his model either because he did not spot it or because the customer failed to mention it in his Specification Of Requirements (SOR). I know because I have encountered both situations in my long career.
Not everyone agrees that direct real-world mapping is facilitated by OOP, or is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction that a program is not a model of the world but a model of a model of some part of the world; "Reality is a cousin twice removed".
OOP is about code re-use
The power of object-oriented systems lies in their promise of code reuse which will increase productivity, reduce costs and improve software quality.Rubbish. This implies that code re-use is possible in OOP and not possible in non-OOP. Using OOP does not guarantee that more reusable code will be available as reusability depends on how the code is written, not the language in which it was written. It is possible to produce libraries of reusable modules in any non-OO language (I know, because I was doing just that with COBOL in 1985) just as it is possible to produce volumes of non-reusable code in any OO language.
It does not matter on the capabilities of the language as it is possible to have the same block of code duplicated in 100 places in any language. It is also possible, in any language, to put that block of code into a reusable module and call that module from those 100 places.
One of the early promises of OOP that I heard many years ago was that it would be possible for a software vendor to produce a library of pre-written classes, and for other developers to use these "off the shelf" classes instead of creating their own custom versions and thus "re-inventing the wheel". This dream never materialised, which just goes to prove that OOP promises much but delivers little.
OOP is about modularity
The source code for an object can be written and maintained independently of the source code for other objects. Once created, an object can be easily passed around inside the system.Rubbish. The concept of modular programming has existed in non-OO languages for many years, so this argument cannot be used to explain why OO is supposed to be better than non-OO. Just as it is possible in any language to hold the source code for an entire application in a single file, it is just as possible, in any language, to break that source code into smaller modules so that the source code for each module can be maintained and compiled independently of all other modules.
OOP is about plugability
If a particular object turns out to be problematic, you can simply remove it from your application and plug in a different object as its replacement. This is analogous to fixing mechanical problems in the real world. If a bolt breaks, you replace it, not the entire machine.Rubbish. This is the same as modularity where the source code for any individual module can be modified, recompiled and inserted into the application without having to touch any of the other modules.
OOP is about information hiding
By interacting only with an object's methods, the details of its internal implementation remain hidden from the outside world.Rubbish. In the first place OO is not about information hiding, it is about implementation hiding. In other words it is the code behind the API which is hidden from view. It is possible to use getters and setters to access the data, but even this is considered to be evil in some circles.
In the second place implementation hiding was never one of the aims of OOP, it is merely a by-product of encapsulation. The outside world can see the method names which can be used on a object, but not the code which exists behind those method names.
In the third place implementation hiding is not unique to OOP as I can distinctly remember in the 1980s writing applications in COBOL which interfaced with a commercial accounting package. The vendor of this package supplied us with a series of pre-compiled subroutines which we could call from our own code. We never saw the source code to any of these subroutines, we merely had a list of APIs and a description of what each API required as input and returned as output. How's that for implementation hiding?
OOP is about the passing of messages.
Message passing is the process by which an object sends data to another object or asks the other object to invoke a method.Rubbish. The way that an object's method is invoked in an OO language is identical to the way in which a function or procedure in a non-OO language is invoked. If the language supports both non-OO functions and object methods (as PHP does) the method of invocation is called "calling", not "message passing". In fact in some languages it is necessary to specify the word "call" when invoking a subroutine.
non-OO: $result = function(arg1, arg2, ...)
OO: $result = $object->function(arg1, arg2, ...)
The result of each invocation is exactly the same - the caller is suspended while control is passed to the callee, and control is not returned to the caller until the callee has finished.
I have worked with messaging software in the past and I can tell you quite categorically that they are completely different:
- In the first place they allow messages to be passed from one process to another, not one module to another in the same process. The only exception I have seen to this was in a language which supported the creation of non-modal forms in which it was possible for one non-modal form to send a message to another non-modal form within the same application instance.
- In the second place their behaviour is totally different:
- They are are asynchronous, which means that after the caller drops a message into the message queue the caller can continue processing and does not have to wait until the callee returns control. E-mail is a classic example of such a messaging system.
- The message queue may be able to contain any number of messages from any number of processes, and the receiving process picks out one message from the front of the queue, processes it, then looks for the next message.
- The message may signify that an acknowledgement be sent back to the caller as soon as it has been received, or it may require a more elaborate result set to be returned after it has been processed.
- In either case the message originator must contain the necessary code to deal with the acknowledgement and/or the result, which is in addition to the code which sends the message.
As you can see the mechanics of activating a method in an object is exactly the same as activating a non-OO function and nothing like passing a message in a messaging system.
OOP is about separation of responsibilities.
Each object can be viewed as an independent little machine with a distinct role or responsibility.Rubbish. It depends entirely on how the module was written, and not the language in which it was written. It is possible to write independent modules in a procedural language such as COBOL, just as it is possible to write non-independent modules in an OO language.
The problem with "separation of responsibilities" is that different people have a different interpretation as to what it actually means. To some people the database operations such as SELECT, INSERT, UPDATE and DELETE require their own objects whereas others put them all together in a single data access object (DAO). Some programmers may have a separate DAO for each table in the database while others may have a single DAO which can deal with any and all database tables. Before you can separate any responsibilities you must first identify what those responsibilities are, and this is a design decision which is totally separate from the language in which the design is ultimately implemented.
In all my many years of experience the only project that I have ever been involved in which failed to be implemented due to "technical difficulties" was one where the system architects were OO "experts" who knew everything about this "separation of responsibilities". They designed a system around design patterns which had a different module for each responsibility which resulted in at least ten layers of code between the user and the database. This made the creation of new components far more complicated and convoluted than it need be, and it made testing and debugging an absolute nightmare. The result was far too expensive for the client, both in time and money, so he pulled the plug on the whole project and cut his losses. A pair of components which took 10 days to build using these "new fangled" OO techniques took me less than an hour to build using my "old fashioned" non-OO methods. So much for the superiority of OO.
OOP is easier to learn.
OOP is easier to learn for those new to computer programming than previous approaches, and its approach is often simpler to develop and to maintain, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than other programming methods.Rubbish. This is just marketing hype. Every new language/tool/paradigm is supposed to be better than everything else, but it rarely is. It is not what you use but how you use it that counts, and I have personally witnessed where an "old" language, when used by competent programmers, regularly out performed a "new" language which was advertised as being more productive by several orders of magnitude.
A person's ability to learn something is often limited by the quality of the teachers or teaching materials, and I'm afraid that too much of what is being taught is too complicated, too inefficient, and more likely to lead to project failures than successes. Too often the teachers insist that there is "only one way" to do OOP, and that is where I most strongly disagree. I have successfully migrated to OOP by ignoring all these so-called experts and drawing on my years of experience with non-OO languages.
As you can see, the above descriptions are either too vague or not specific to OOP, so they cannot be used as distinguishing features.
Tutorial pages:
|
|
|||||||||
You might also want to check these out:
|
Leave a Comment on "What is Object Oriented Programming (OOP)?"
You must be logged in to post a comment.
Link to This Tutorial Page!
