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

14

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

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

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

object-oriented functional-programming Кха Нгуён
источник
см. Обсудить этот $ {блог}
комнат
Жаль, что это закрыто - это приводило к некоторым хорошим обсуждениям. Посмотрите на функции первого класса как стартер.
Робби Ди,
1
@ Эйфорические вопросы типа обсуждения фактически разрешены, но какие вопросы являются субъективными, могут быть ... субъективными.
Робби Ди,
2
Я считаю, что это интервью было проведено до того, как Джо Армстронг написал свою кандидатскую диссертацию. Во время написания своей кандидатской диссертации Армстронг узнал о реальном определении ОО и понял, что Erlang на самом деле является полностью объектно-ориентированным, по сути, из всех современных основных языков, Erlang, вероятно, самый объектно-ориентированный язык! Он не сделал бы такое заявление таким образом, если бы знал, что Эрланг на самом деле является языком оО. Он говорит об окружающем авторитете , который абсолютно не имеет никакого отношения к ОО.
Йорг Миттаг
1
Привет, мой вопрос о предоставлении некоторого примера кода, который помогает мне (и другим) лучше понять проблему. Любой фрагмент кода, который демонстрирует проблему, является приемлемым, а не просто мнением.
Ха Нгуен

Ответы:

16

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

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, что упрощает рассуждение.

Euphoric
источник
И наоборот, хотя функциональные языки поддерживают функции первого класса из коробки - это не значит, что функция X может безопасно использоваться функцией Y без побочных эффектов.
Робби Ди,
Хотя вы делаете отличное замечание, я думаю, что вы можете немного сойти с трассы здесь. Цитата явно упоминает об окружающей среде, а не о том, как был разработан код.
Робби Ди
@RobbieDee The Monkeyи Jungleсреда для Banana. Вводя подобное абстракция IBananaOwner, среда становится явной. А как устроена эта среда, такова его проблема.
Эйфорическая
Вы вполне можете быть правы, но я не могу не подумать, прочитав это среди прочего, что слон в комнате (чтобы добавить еще одно животное) заключается в том, что проблема заключается в правильной композиции функций, которые исторически сложились в функциональном программировании. одолжил себе больше.
Робби Ди
@RobbieDee Вы не можете заменить написанное мной простой композицией функций. По крайней мере, за пределами игрушечного примера проблемы. На практике, чтобы полностью заменить дизайн ООП, необходимы такие вещи, как сложные обобщения, классы типов, монады и другие. И это просто меняет один вид сложности на другой.
Эйфорическая
13

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

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

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

Дэвид Арно
источник
1
Это не отвечает на вопрос, так как у него нет примера кода ...
Робби Ди