Does OOP suck? I think it does if you are from a functional programming background. Similarly, functional programming can be Greek to you if you are from the imperative programming background. It is a classic OOP v/s FP discussion. I do agree with the author on certain points, but not all.
However I would like to present my views on certain points mentioned in that article.
Data Structure and Functions
Binding the data structure and functions together is the principle objection. As I understand, the purpose itself is not binding together, but the purpose is to restrict access to the data only through a certain set of methods. Of course, this can always be followed as a discipline, but binding the data and the operations together can help you do it by design. Note that I mentioned operations that operate on the data. The moment you start including other operations, OOP can start sucking.
Using the invariant as a guideline for designing can help in such cases.
Hiding the State
I might not have understood this entirely. Is it always necessary to hide the state? The aim of encapsulation is to hide unncessary data. It avoids information overload, and it maps information with responsibility. If the state is meant to be internal, that is, nothing relevant to the user, it should definitely be hidden.
Maybe I misunderstood what the author meant by hidden. Is restricting access to the state through an access method hiding? Hiding is not providing any access at all.
Another perspective is that this can help you use abstraction to build a layer that the user can understand. It is not only about hiding but also about modeling in the user’s language.
Motivation behind OOP
Finally, I believe the real motivation behind OOP is to follow the real world as closely as possible. The tools of abstraction and encapsulation can be used to separate what from how, in fact focus on what before thinking about how. Interface can be effectively employed to build rules of communication between various entities.
Of course it is not that OOP enables you to do something that is impossible otherwise. Neither does it reduce complexity. It can, however, help you in breaking down the complexity into manageable pieces. Whether an industry is required or not, real world has complexities and developing software is complex. OOP is not simple, you have to think and design and code. In my opinion, OOP is quite beneficial, rather it can be beneficial depending upon how it gets applied. If not, it sure sucks.
April 11th, 2007 at 4:39 am
I’ve struggled with this for the past ten years. The mantra is, “Everything has to be object oriented.” There are so many areas where zealots make things harder than they need to be. In reality, I write hybrid code, somewhere between purely procedural and purely object oriented. I recognize some of the benefits of OOP, but I can’t afford the time requirements to design and build a pure architecture. The best design is simple, easy to deploy, and easy to maintain, regardless of the methodology.
What’s interesting is the fact that someone can actually come out and say something negative about OOP. That would surely have gotten you burned at the stake a few years ago.
April 11th, 2007 at 1:27 pm
Shannon, I agree with you that sometimes a hybrid code is quicker to get out with. But I believe that OOP is seen more in the design than in the code. OOP concepts can be applied even in the procedural paradigm.
I also agree with you that design should be simple and easy to work with irrespective of the methodology. I we start feeling that something like OOP is making it complex, probably OOP is an overkill for it. Having said that, the concepts of interface, the separation of concerns and identifying roles and responsibilities are universal.
October 23rd, 2007 at 10:52 am
[...] from this, I think OOP is extremely useful, even without the syntax and the [...]