Código de exemplo para explicar o problema da Banana Monkey Jungle por Joe Armstrong [fechado]

No livro Coders at work, Joe Armstrong afirmou que:

Eu acho que a falta de reutilização vem nas linguagens orientadas a objetos, não nas linguagens funcionais. Como o problema das linguagens orientadas a objetos é que elas têm todo esse ambiente implícito que carregam consigo. Você queria uma banana, mas o que você conseguiu foi um gorila segurando a banana e toda a selva

Eu não entendo bem aqui. Se o problema é obter uma banana, podemos encapsular toda a lógica por trás da função 'getBanana'. Como o macaco e a selva estão envolvidos nesse contexto? Alguém poderia escrever um trecho de código que explica o problema em um mais fácil de entender, por exemplo, demonstrar o fato de que o Bananaobjeto requer o Monkeye Jungleobjetos para ser iniciado, por favor?

Ele está sugerindo que a maioria dos programas reais de POO não respeita a separação de preocupações. Por exemplo, você poderia ter classes:

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

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

public class Jungle
{
}

Se você usar Banana, é temporariamente necessário também depender de Monkeye Jungle.

Mas eu discordo totalmente que isso é um problema com OOP e que o estilo funcional de alguma forma não o possui. Isso pode ser facilmente corrigido no OOP com a introdução da abstração correta.

O problema é mais sobre os desenvolvedores que não se preocupam com a separação de preocupações. E eu não teria medo de afirmar que a maioria dos programadores de POO são iniciantes, enquanto os programadores funcionais têm alguma experiência que os motiva a separar adequadamente seu código.

A abstração possível pode ser:

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

public interface IBananaOwner
{
}

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

public class Jungle
{
}

Dessa forma, você sabe que Bananatem dono, mas não precisa ser Monkey. Pode ser qualquer coisa. E limita o que pode ser Bananafeito com o proprietário apenas às operações definidas por IBananaOwner, o que simplifica o raciocínio.

Gorilas não são macacos!

Deixando isso de lado, você responde sua própria pergunta com " podemos encapsular toda a lógica por trás da função 'getBanana' ". Tudo o que eu quero é uma banana, mas para obtê-la eu preciso chamar getBananaalgum objeto, por exemplo, uma instância da Gorillaclasse. Esse objeto de banana provavelmente contém uma referência ao gorila ao qual pertence e esse objeto, por sua vez, terá uma referência à floresta à qual pertence. Por isso, peço uma banana, mas encapsulada por trás, está toda a selva.

É um exemplo extremo e nem sempre será tão ruim assim. Mas não é incomum acabar com um sistema OO como este. E assim, para testar esse getBananamétodo, preciso instanciar ou zombar de uma floresta inteira.