Object Orientation and Fallacies of Perception
Object Orientation and Fallacies of Perception
All about object-oriented programming—one of the great grandfathers of modern software development techniques—and fallacies of perception.
Join the DZone community and get the full member experience.Join For Free
Object-oriented programming is one of the great grandfathers of modern software development techniques.
Think about this. Term “Object-Oriented Programming” (OOP) was coined by Alan Kay in 1966 or 1967 while he was at grad school.! Lyndon B. Johnson was US president. Before email, cell phones, and other tech goodies which we have today. We wrote a lot of letters then. Someday, when I have indulged a bit too much I’ll probably get an OOP Tattoo.
I have recently read few articles which focus on the cons of using object-oriented design in building software and some of those were fun to read and that’s in its shows the passion of the author that he/she was able to write it in an easy to understand way. One particular example, I like was an analogy of a banana.
The analogy describes OOP as like, “if you ask for a banana, what you get is a gorilla, with a banana in hand and the whole jungle with it”.
some of those articles sometimes go a bit further and even almost convince you that most of the issues software struggle with are those of OOP designs, a typical remedy they suggest is to favor composition over OOP.
As much fun or emotional roller coster those articles are I do not fully agree with the theme that OOP is the problem. In this post, I would like to share my thoughts about OOP and also am very much interested in knowing your opinion as well on the subject matter.
What I think, is, first of all, the composition is also a style of doing OOP and it is just like arranging objects in a specific way, that’s all. All the OOP goodness still there and I think the real problem is not about using OOP in your software design but rather is a side-effect of applying it wrong or using it in a place where that piece of software is not yet ready to benefit from the true power of OOP.
What Are OOP Principles?
I asked or answer this question many times and you might have your definition of these. A typical answer normally is a definition or mention of Inheritance, Polymorphism, etc. Though technically correct these are the consequences of applying OOP but not the generating force behind it which is the capability to have data along with operations that operate on that data structure. I am not saying that those concepts like Inheritance, Polymorphic behavior, etc are not important, what my focus is that ability to group data and operations is the driving force behind those principles.
OOP is a Ubiquitous Design Tool
Let's see how OOP is already being used and maybe you are already using it in a non-traditional manner and not aware of it. First of all, outside the code, the OOP symbols, terminologies, and its ubiquitous nature of describing or empowering software discussions is one of its biggest use. It's so powerful that we sometimes even did not realize it. For example, so far, I haven’t mentioned a single object-oriented programming language in this post and we are discussing software design neutrally. So, that is it's one of the biggest use outside actual code.
Second, as a human, we have a different process of operating in the world than a machine. Though I am a big fan of technology same time fascinated by how we as humans tackle complexity. We might be not fast like computers (I believe some might not agree with that statement, but let's say for the sake of argument, assume, computers are faster ) but we are still smart and we learn quickly and can reason about things which we never encountered before (computers are catching up though). So, how this all related to OOP. The point I want to make, is that OOP design and style is for humans first and yes it is also possible to have some speed or accuracy benefits from it in code as well, but that is a secondary goal, the first goal is to have software complexity in-check and make it easier to understand and work with for humans and If you were expecting a speed gain through OOP then you are on the wrong side of the history.
Then there are programming languages and their implementation details and that’s the place where this all boils down to actual code you write in that specific programming environment. It is at the very end where there a programmer needs to know about language-specific syntax and the funny (or maybe sad) thing is that this implementation details area in which 90% of current programming literature is focused, these are a small subset of object-oriented mindset.
Certain programming language’s syntax and implementation details are rules we need to abide by when implementing OOP in our software but those should not drive our OOP thinking and problem-solving approaches. When your design operates in the bounds of programming environments, you will encounter various other object types e.g. a button object, a TCP-Socket object, etc. and somehow your design or core domain model (which is built using objects) have to interact with those in one way or another and you have to maintain a balance so that your code can interact with those environment objects and those details do not leak into your domain objects. Sometimes it can not be avoided or maybe allowing those leaks into your business objects might simplify your coding effort and that is not a bad thing but this time you are making an educated decision and you should not fight it.
So, OOP is not just about writing code, its a practice to make code more understandable, maintainable, and extendable as well. The coding part is just a small detail in the grand scheme of things.
Programming is Not a Religion
Religious or historic facts can be the inspiration for certain programming techniques but there is not a single right-way to code software. When we write software we try to solve a problem in a way that serves the purpose. Sometimes its time to market, that is a priority. Other times, it's a different priority. The quest to find the right way requires you to do some research and come up with some ideas to solve that problem. It might not be a perfect solution but now you have some foundation to built on it. This phase will require continuous discussions and learning from various mistakes and that time it should not be our concern that we are applying OOP concepts or not.
It is mostly afterward that we understand the problem domain better and then structure our code in a way that follows OOP design guidelines so that it is understandable to other peoples as well while still having internal consistency and best practices backed into it. That is the object orientation which is inspired by real-world objects, a real-world car, a person, and on top of that, you have the power of creating your objects and maybe built those for the purpose better fit.
You can find inspirations from literature, from the real world or discussions with domain experts and build your model and then translate that model using the constructs provided by programming languages and when it comes to programming, there are multiple ways of doing so and you might favor one way than the other and that’s how it should be.
If your design is simple to understand by others and has the potential to extend then that is a good start and it will evolve. I think one of the reasons that you might be struggling with OOP approaches in code, is that you apply it too early and just as it is mentioned in textbooks. Give it a little more thinking, time, and apply it once you think your design is now in a need for OOP practices. Some code areas are not that complex and applying sophisticated programming techniques like OOP to that area makes things unnecessarily complicated.
Programming languages, types, best practices, etc are tools to bring order to the chaos of 1s and 0s. It's all about controlling complexity, defining boundaries, and reasoning about the problem domain and it is not easy either. Take your time to understand, think of a model and then apply it, don’t wait much to get design perfect but rather improve it gradually.
OOP is not necessarily evil. You should use it where your domain model needs it naturally. Do not get discouraged by if u hear or read some negative thoughts about it. Use it for your benefit, not just for the sake of applying it without need. Ignore it if your problem domain is not complex. Take small steps and if possible try not to use it from the very beginning in your new code. Feel free to share your thoughts on this topic with me. Does anyone want to come with me to get that tattoo?
Published at DZone with permission of Jawad Hasan Shani . See the original article here.
Opinions expressed by DZone contributors are their own.