Banana Gorilla Jungle — OOP
From the famous quote,
“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang progamming language
This explains the class depends on class problems. You want to use ‘Banana’ but end up importing Gorilla then the whole things that Gorilla depends on like other object states and environment i.e. jungles.
This is a problem of ‘tight coupling’ class inherit from class.
Why we got this?
At a first glance, this is kind of weird why banana needs gorilla.
But at the time of writing banana, it might be just an extension embedded in the gorilla without knowing someone will want to just call banana alone. Banana is ‘encapsulated’. So this look like:
Jungle.getAnimalByName('Gorilla no.1').getBanana()Assumption how this might happen?
Without a good OO system planning, for the system that have classes A,B,C we just finish coding class A then adding up some features then call it B then adding some more features then call it C. Now we got:
A {} // e.g. animals
B extends A{} // e.g. animals with four legs
C extends B {} // e.g. animals with four legs holding bananaSomeone might do this through import without recognizing it especially for the language that one class belongs to one file.
file class Banana: import Gorilla
... code how Banana relate to Gorilla...file class Gorilla: import Jungle
... code how Jungle relate to Gorilla...
This approach is easier than defining ‘interface’ and use design pattern to avoid this coupling. This requires some experiences, time to design and time to organize code. And as you know, we don’t have time.
So that we tend to end up seeing this unintentional weird inheritance and dependency Gorilla holding Banana in the real life.
Cheers!
Modern web app development and artificial intelligent.
