Object Orientation and Fallacies of Perception

Introduction

Object oriented programming is the 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 actually 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 focuses on the cons of using object oriented design in building software and some of those were really fun to read and that’s in its own 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 describe 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 futher 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, 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 is 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 own definition of these. A typical answer normally is a definition or mention of Inheritance, Polymorphisam 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 operates 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 together data and operations is the driving force behind those principles..

OOP as an ubiquitous design tool

Lets see how OOP is already being used and may be 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. Its so powerful that we sometime even did not realize it. For example, so far, I haven’t mention a single object oriented programming language in this post and we are discussing software design neutrally. So, that is its one of the biggest use outside actual code.

Second, as a human, we have a different process of operating in world than machine. Though, I am a big fan of technology but 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 lets say for the sake of argument, assume, computers are faster ) but we are still smart and we learn quickly and are able to 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, 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 need to know about language specific syntax and funny (or may be sad) thing is that this implementation details area 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 nevertheless 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 some how 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 is able to interact with those environment objects and those details does not leak into your domain objects. Sometimes it can not be avoided or may be 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. Coding part is just a small detail in 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 priority. Other time, its a different priority. The quest to find right way require 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 afterwards 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 own objects and may be built those for the purpose better fit.

You can find inspirations from literature, from real world or from 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 have potential to extend then that is a good start and it will evolve over the time. I think one of the reason that you might be struggling with OOP approaches in code, is that you apply it too early and just as it is mentioned in text books. 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 those area make things unnecessarily complicated.

Programming languages, types, best practices etc are tools to bring order to the chaos of 1s and 0s. Its all about controlling complexity, defining boundaries and reasoning about 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.

Summary

OOP is not necessarily an 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. Anyone want to come with me for that tattoo?