Sample code to explain Banana Monkey Jungle problem by Joe Armstrong [closed]

Question

In the book Coders at work Joe Armstrong stated that:

I think the lack of reusability comes in object oriented languages, not in functional languages. 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

I do not quite get it here. If the problem is to get a banana, we can encapsulate all the logic behind the function 'getBanana'. How are monkey and jungle involved in this context. Could somebody write a code snippet that explains the problem in an easier to understand way, say, demonstrate the fact that the Banana object requires the Monkey and Jungle objects to be initiated, please?

Answer 1

He is hinting at a fact, that majority of real OOP programs don't respect separation of concerns. For example, you could have classes:

public class Banana
{
    public Monkey Owner {get;}
}

public class Monkey
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

If you use Banana, it is transitively necessary to also depend on Monkey and Jungle.

But I would strictly disagree that this is problem with OOP and that functional style somehow doesn't have it. This can easily be fixed in OOP with introduction of right abstraction.

The problem is more about developers not caring about separation of concerns. And I would not be afraid to assert that majority of OOP programmers are novices, while functional programers have some experience, that motivates them to properly separate their code.

Possible abstraction might be:

public class Banana
{
    public IBananaOwner Owner {get;}
}

public interface IBananaOwner
{
}

public class Monkey : IBananaOwner
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

This way, you know that Banana has owner, but it doesn't have to be Monkey. It can be anything. And it limits what can Banana do with owner to only operations defined by IBananaOwner, which simplifies reasoning.

Answer 2

Gorillas are not monkeys!

Leaving that aside, you answer your own question with "we can encapsulate all the logic behind the function 'getBanana'". All I want is a banana, but to get it I need to call getBanana on some object, eg an instance of the Gorilla class. That banana object then likely contains a reference to the gorilla it belongs to and that gorilla object will in turn have a reference to the forest it belongs to. So I ask for a banana, but encapsulated behind that is the entire jungle.

It's an extreme example and won't always be that bad. But it's not uncommon to end up with an OO system like this. And so, to test that getBanana method, I need to instantiate, or mock, an entire forest.