Зразок коду для пояснення проблеми «Джунглями бананової мавпи» Джо Армстронга [закрито]

У книзі Кодери на роботі Джо Армстронг заявив, що:

Я думаю, що недостатня можливість використання повторюється в об'єктно-орієнтованих мовах, а не у функціональних мовах. Тому що проблема з об'єктно-орієнтованими мовами полягає в тому, що вони мають все це неявне середовище, яке вони несуть із собою. Ви хотіли банана, але те, що у вас було, - це горила, яка тримає банан і цілі джунглі

Я тут не зовсім розумію. Якщо проблема полягає в тому, щоб отримати банан, ми можемо інкапсулювати всю логіку функції "getBanana". Як мавпа та джунглі беруть участь у цьому контексті. Може чи хто - небудь написати фрагмент коду , який пояснює проблему легше зрозуміти , як, скажімо, продемонструвати той факт , що Bananaоб'єкт вимагає , Monkeyі Jungleоб'єкти повинні бути ініційована, будь ласка?

Він натякає на те, що більшість реальних програм ООП не поважають розділення проблем. Наприклад, у вас могли бути заняття:

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

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

public class Jungle
{
}

Якщо ви використовуєте Banana, транзитивно необхідно також залежати від Monkeyі Jungle.

Але я категорично не погоджуюся, що це проблема з OOP, і що функціональний стиль якось не має цього. Це можна легко зафіксувати в ООП із введенням правильної абстракції.

Проблема полягає більше в тому, що розробники не піклуються про розділення проблем. І я б не побоявся стверджувати, що більшість програмістів OOP - початківці, тоді як функціональні програмісти мають певний досвід, який мотивує їх правильно розділяти код.

Можливою абстракцією може бути:

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класу. Цей банановий об’єкт тоді, ймовірно, містить посилання на горилу, якій він належить, і цей об’єкт горили, в свою чергу, матиме посилання на ліс, до якого він належить. Тому я прошу банана, але за ним укладений весь джунгль.

Це надзвичайний приклад і не завжди буде таким поганим. Але не рідкість опинитися в такій системі ОО. І тому, щоб перевірити цей getBananaметод, мені потрібно придумати чи знущатися над цілим лісом.