Пример кода, объясняющего проблему джунглей «Банановые обезьяны», Джо Армстронг [закрыто]

В книге « Кодеры за работой» Джо Армстронг заявил, что:

Я думаю, что отсутствие возможности повторного использования происходит в объектно-ориентированных языках, а не в функциональных языках. Поскольку проблема с объектно-ориентированными языками заключается в том, что у них есть вся эта неявная среда, которую они носят с собой. Вы хотели банан, но получили гориллу с бананом и джунглями

Я не совсем понимаю это здесь. Если проблема заключается в том, чтобы получить банан, мы можем инкапсулировать всю логику функции getBanana. Как обезьяна и джунгли участвуют в этом контексте. Может ли кто - нибудь написать фрагмент кода , который объясняет проблему легче понять , как, скажем, продемонстрировать тот факт , что Bananaобъект требует , Monkeyи Jungleобъекты должны быть инициирована, пожалуйста?

Он намекает на факт, что большинство реальных ООП-программ не уважают разделение интересов. Например, вы можете иметь классы:

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

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

public class Jungle
{
}

Если вы используете Banana, переходно необходимо также зависеть от Monkeyи Jungle.

Но я бы категорически не согласился с тем, что это проблема с ООП и что функциональный стиль как-то не имеет ее. Это легко исправить в ООП с помощью правильной абстракции.

Проблема больше в разработчиках, не заботящихся о разделении интересов. И я не побоялся бы утверждать, что большинство программистов ООП являются новичками, в то время как у функциональных программистов есть некоторый опыт, который мотивирует их правильно разделять свой код.

Возможная абстракция может быть:

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

public interface IBananaOwner
{
}

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

public class Jungle
{
}

Таким образом, вы знаете, что у Bananaнего есть владелец, но это не обязательно Monkey. Это может быть что угодно. И это ограничивает то, что может Bananaсделать с владельцем только операциями, определенными IBananaOwner, что упрощает рассуждение.

Гориллы не обезьяны!

Оставляя это в стороне, вы отвечаете на свой вопрос: « мы можем инкапсулировать всю логику функции getBanana ». Все, что я хочу, это банан, но чтобы получить его, мне нужно вызвать getBananaкакой-то объект, например, экземпляр Gorillaкласса. Тогда этот банановый объект, вероятно, содержит ссылку на гориллу, которой он принадлежит, и этот объект гориллы, в свою очередь, будет иметь ссылку на лес, которому он принадлежит. Поэтому я прошу банан, но за ним скрываются целые джунгли.

Это крайний пример, и он не всегда будет таким плохим. Но нередко бывает, что такая система OO выглядит так. Итак, чтобы протестировать этот getBananaметод, мне нужно создать экземпляр всего леса.