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.
This is a problem of ‘tight coupling’ class inherit from class.
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:
From the famous quote,
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:
Someone might do this through import without recognizing it especially for the language that one class belongs to one file.
“… 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.
At a first glance, this is kind of weird why banana needs gorilla.
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…