When I was introduced to functional programming, it felt wrong, and I realized a bit later that it was so because I came from OOP background. Just like people used to other programming paradigms criticise OOP. The unfamiliarity makes us focus on disadvantages of an approach, ignoring its benefits. I do not think I can deny the objects, but I will try to re-present some of the points from the perspective of OOP programming.
The aim of an object is to represent an entity which knows about its structure and its methods. You can also say that it represents an entity which is aware of its data or knowledge in some cases, and its responsibilities. This gives us a clean way of identifying various entities and assigning responsibilities to them. I like to test a class design by using the responsibility, knowledge and authority triad. I think the problem here is that many programmers do not give enough time to design which often results in bloated classes. Guidelines like using the invariant to design a class are ignored. I think this practice can be followed in design, even if we choose other programming paradigms.
The second objection of “Everything has to be an object” is quite valid. There is a ongoing tussle even within the OO community about this. And I think the OOP community understand the concerns raised by the author here, which is why features like static datastill exist.
Data type definitions being distributed has its pros and cons. It helps us modularize the code to an extent that we can physically isolate disparate entities. Of course, this approach makes it difficult to have data structures that get used across the code base. That is why it is common to have a utility package or common package.
State is the root of the evil, and side effects account for most of the bugs. However, there is no point in blaming OOP for it, these are characteristics of imperative programming. The private state helps the designer to add central control over their access and modification by someone else. Is this good or bad? It depends on the need of that hour. That is why the visibility can be changed. Again, this gets terribly misused if the class gets bloated and we end up with many methods modifying the state.
Finally, OOP is a design approach, and like everything else it has its pros and cons. However, it has been created with a purpose and hence with certain guidelines. The reasons that the author mentions for OOP’s popularity perhaps shows some ignorance. OOP gave a chance to the developers to model the real world, and gave various tools to follow best practices of software engineering. However, the reasons do highlight the myth of OOP being easy to learn. It is not, and I wish every OOP programmer acknowledged this before starting with it.
February 27th, 2010 at 6:33 am
Well, I have my background on Asm (m68k/x86) and C and, of course, I did also take a look at OOP.
Your article about pros/cons of OOP isn’t that bad.
But I disagree to a point, that OOP really models the real world.
It more models the world, how human beings think of their reality.
In truth, we can not split objects into each other, since everything is one.
Consider, for example, just our physical body, In biology we split it into heart, brain, chest, etc.
But all these entities require each other to operate as they should.
Our heart can’t act without our brain and vice versa.
The same is true for our surrounding nature, a tree can’t act without O2 and H2O. There isn’t a real delimitation of physical entities. Splitting is all in our mind.
The same way, I think we should act/think on developing.
A well-designed function is not dependant of its caller, but even a well-designed method of a class is.
Also nature doesn’t know of private, protected and public elements.
In nature, you have public access to any object (I know it can sometimes be hard to decode the mechanism, but decoding that usually is only a matter of time to resolve).
That’s also what non-OOP coding does, you have really full access to anything, but you should know what you do!
But again, no difference…nature doesn’t prohibit you producing that atomic bomb, it will just let you do and after that let you experience all the problems coming with it!
I still think that OOP is useful when programming graphical user interfaces, because in that case, you usually deal only with the surface of these objects (i.e. you change the background color of a GUI object, but not the way how the GUI object changes its background color).
To summarize up, if OOP really would represent our true world, then EVERY object, yes, really EVERY object that was ever designed should have some kind of dependency on some other, to there is no missing link in ANY object ever designed out there to each other, or to say it in graph theory, every object has to be reachable just traversing the complete dependency chain.