Przykładowy kod wyjaśniający problem Banana Monkey Jungle autorstwa Joe Armstronga [zamknięty]

W książce Coders at work Joe Armstrong stwierdził, że:

Myślę, że brak możliwości ponownego użycia występuje w językach obiektowych, a nie w językach funkcjonalnych. Ponieważ problem z językami obiektowymi polega na tym, że mają one całe to ukryte środowisko, które ze sobą niosą. Chciałeś banana, ale dostałeś goryla trzymającego banana i całą dżunglę

Nie do końca to rozumiem. Jeśli problemem jest zdobycie banana, możemy zawrzeć całą logikę funkcji „getBanana”. Jak zaangażowane są małpy i dżungla w tym kontekście. Czy ktoś mógłby napisać fragment kodu wyjaśniający problem w łatwiejszy do zrozumienia sposób, powiedzmy, wykazujący fakt, że Bananaobiekt wymaga zainicjowania obiektów Monkeyi Jungle?

Wskazuje na fakt, że większość prawdziwych programów OOP nie szanuje podziału problemów. Na przykład możesz mieć klasy:

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

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

public class Jungle
{
}

Jeśli używasz Banana, tranzytowo konieczne jest również poleganie na Monkeyi Jungle.

Ale zdecydowanie nie zgadzam się, że jest to problem z OOP i że styl funkcjonalny jakoś go nie ma. Można to łatwo naprawić w OOP dzięki wprowadzeniu odpowiedniej abstrakcji.

Problem polega bardziej na tym, że programiści nie dbają o rozdzielenie problemów. I nie bałbym się stwierdzić, że większość programistów OOP to nowicjusze, podczas gdy programiści funkcjonalni mają pewne doświadczenie, które motywuje ich do właściwego rozdzielenia kodu.

Możliwą abstrakcją może być:

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

public interface IBananaOwner
{
}

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

public class Jungle
{
}

W ten sposób wiesz, że Bananama właściciela, ale nie musi tak być Monkey. To może być wszystko. I ogranicza to, co może Bananazrobić z właścicielem, tylko do operacji zdefiniowanych przez IBananaOwner, co upraszcza rozumowanie.

Goryle to nie małpy!

Pozostawiając to na boku, odpowiadasz na swoje własne pytanie „ możemy zawrzeć całą logikę stojącą za funkcją„ getBanana ” ”. Wszystko czego chcę to banan, ale aby go zdobyć, muszę wywołać getBananajakiś obiekt, np. Instancję Gorillaklasy. Ten obiekt bananowy prawdopodobnie zawiera odniesienie do goryla, do którego należy, a ten obiekt goryla będzie z kolei miał odniesienie do lasu, do którego należy. Proszę więc o banana, ale za tym kryje się cała dżungla.

To ekstremalny przykład i nie zawsze będzie taki zły. Ale nierzadko kończy się na takim systemie OO. Aby przetestować tę getBananametodę, muszę utworzyć instancję lub wyśmiewać cały las.