The Banana and the Gorilla Problem
This article discusses the downside to object oriented programming when it comes to reusability.
“You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” — Joe Armstrong
This quotation is often referenced when discussing the discourse of using an object oriented language; the idea behind this metaphor is that a programmer cannot work on a ‘banana’, a piece of code in isolation , you will always end up importing the gorilla attached to the banana— there are always dependencies behind it and what the “banana” inherits from its parental class.
Curiously, a con to object oriented programming includes the idea of reusability. As a review, writing code with a goal of separating functions as opposed to inheritance, the idea of inheriting behavior from super classes or functions, allows programmers to separate code into smaller chunks, creating the idea that the parts created sum together to generate the whole application or software.
The problem with inheritance and reusability in object oriented programming:
Historically, inheritance is an important idea for programmers to comprehend: if we break down the idea of inheritance more, it allows functions that are parameterized by other functions; functions that hand off behavior to other functions; classes handing off behavior to subclasses, etc. If a programmer wanted to reuse the functionality of a code, they would have to not only plan for the changes in behavior of their code entirely, but they would need to abstract their code further.
Robert Martin, also known as ‘Uncle Bob’ in the software engineering community architected relevant software design principles such as SOLID, a mnemonic programmers can use to remember the best design principles when developing their code; each SOLID principle solely stands to improve the maintainability of object oriented applications and software components. SOLID stands for:
- Single Responsibility Principle
- Open/Close Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle.
With focus to the Dependency Inversion Principle, it states that
“high level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions” ().
An example of high level modules includes ActiveRecord in Ruby on Rails. ActiveRecord is the parent class or module in Ruby on Rails and it delegates high level functionality (e.g., data validations, search for records in a database, etc.). The most straightforward usage of this example is to think of active record as a CEO of a company. The CEO of the company will perform CEO duties: manages the overall operations of the company, acts as the main point of communication between a board of directors and corporate, etc. While ActiveRecord performs duties regarding database functionality and storage recall, a lower level worker in the company, a truck driver will perform truck driver duties. A CEO of a company will not be performing lower level functionality or work. A class, for example a User class in Ruby will listen for instructions by ActiveRecord and perform duties (i.e., fire off methods)in response to what it is listening for.
What does this have anything to do with a banana and a gorilla?!
Well, the idea behind the banana and gorilla is a cautionary tale of poorly designed code in object oriented programming. To avoid the banana and the gorilla problem, remember that higher level functionality stays with higher level functions and separating that from lower level classes or functions. When constructing code from the start, produce code that is abstracted enough; create code where functionality of the parent class stays with higher level functionality.
Conclusion:
While object oriented programming is one of the most popular programming paradigms to follow, many languages, such as Java, C++, C#, Python, R, etc. use the object oriented programming paradigm. Keeping in mind that many of the worlds most popular programming languages are object oriented, running into problems of inheritance is a common issue, but is no feat to solve. Separating your code and following the SOLID principles to creating amazing, well structured applications is one way to resolve and evade tracing issues through out your code. The cautionary tale of the gorilla and the banana stands as a resolute lessons throughout programming even better applications. So, in the mean time, separate your code to avoid dependency issues or even worse, breaking your code entirely.