Código de muestra para explicar el problema de Banana Monkey Jungle por Joe Armstrong [cerrado]

En el libro Codificadores en el trabajo, Joe Armstrong declaró que:

Creo que la falta de reutilización viene en lenguajes orientados a objetos, no en lenguajes funcionales. Debido a que el problema con los lenguajes orientados a objetos es que tienen todo este entorno implícito que llevan consigo. Querías un plátano, pero lo que obtuviste fue un gorila sosteniendo el plátano y toda la jungla

No lo entiendo bien aquí. Si el problema es obtener un plátano, podemos encapsular toda la lógica detrás de la función 'getBanana'. ¿Cómo se involucran los monos y la jungla en este contexto? ¿Podría alguien escribir un fragmento de código que explique el problema de una manera más fácil de entender, por ejemplo, demostrar el hecho de que el Bananaobjeto requiere que se inicien los objetos Monkeyy Jungle, por favor?

Está insinuando un hecho, que la mayoría de los programas reales de OOP no respetan la separación de las preocupaciones. Por ejemplo, podrías tener clases:

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

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

public class Jungle
{
}

Si lo usa Banana, es transitivamente necesario depender también de Monkeyy Jungle.

Pero estoy estrictamente en desacuerdo con que este es un problema con OOP y que el estilo funcional de alguna manera no lo tiene. Esto se puede solucionar fácilmente en OOP con la introducción de la abstracción correcta.

El problema es más sobre los desarrolladores que no se preocupan por la separación de las preocupaciones. Y no tendría miedo de afirmar que la mayoría de los programadores de OOP son novatos, mientras que los programadores funcionales tienen cierta experiencia, que los motiva a separar adecuadamente su código.

La posible abstracción podría ser:

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

public interface IBananaOwner
{
}

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

public class Jungle
{
}

De esta manera, sabes que Bananatiene dueño, pero no tiene que ser así Monkey. Puede ser cualquier cosa. Y limita lo que puede Bananahacer con el propietario a solo operaciones definidas por IBananaOwner, lo que simplifica el razonamiento.

¡Los gorilas no son monos!

Dejando eso de lado, usted responde su propia pregunta con " podemos encapsular toda la lógica detrás de la función 'getBanana' ". Todo lo que quiero es un plátano, pero para obtenerlo necesito invocar getBananaalgún objeto, por ejemplo, una instancia de la Gorillaclase. Ese objeto de plátano probablemente contenga una referencia al gorila al que pertenece y ese objeto del gorila a su vez tendrá una referencia al bosque al que pertenece. Entonces pido un plátano, pero encapsulado detrás de eso está toda la jungla.

Es un ejemplo extremo y no siempre será tan malo. Pero no es raro terminar con un sistema OO como este. Y así, para probar ese getBananamétodo, necesito crear una instancia o simular un bosque completo.