Beispielcode zur Erklärung des Banana Monkey Jungle-Problems von Joe Armstrong [geschlossen]

In dem Buch Coders at work erklärte Joe Armstrong:

Ich denke, der Mangel an Wiederverwendbarkeit tritt in objektorientierten Sprachen auf, nicht in funktionalen Sprachen. Weil das Problem mit objektorientierten Sprachen darin besteht, dass sie all diese implizite Umgebung haben, die sie mit sich herumtragen. Sie wollten eine Banane, aber Sie bekamen einen Gorilla, der die Banane und den gesamten Dschungel hielt

Ich verstehe es hier nicht ganz. Wenn das Problem darin besteht, eine Banane zu bekommen, können wir die gesamte Logik hinter der Funktion 'getBanana' zusammenfassen. Wie sind Affen und Dschungel in diesem Zusammenhang involviert? Könnte jemand ein Code-Snippet schreiben, das das Problem leichter verständlich erklärt, beispielsweise die Tatsache demonstrieren, dass für das BananaObjekt das Monkeyund die JungleObjekte initiiert werden müssen, bitte?

Er deutet auf eine Tatsache hin, dass die Mehrheit der echten OOP-Programme die Trennung von Bedenken nicht respektiert. Zum Beispiel könnten Sie Klassen haben:

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

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

public class Jungle
{
}

Wenn Sie verwenden Banana, ist es transitiv notwendig, auch von Monkeyund abhängig zu sein Jungle.

Aber ich würde absolut nicht zustimmen, dass dies ein Problem mit OOP ist und dass der funktionale Stil es irgendwie nicht hat. Dies kann in OOP mit der Einführung der richtigen Abstraktion leicht behoben werden.

Das Problem besteht eher darin, dass Entwickler sich nicht um die Trennung von Bedenken kümmern. Und ich hätte keine Angst zu behaupten, dass die Mehrheit der OOP-Programmierer Anfänger sind, während funktionale Programmierer einige Erfahrungen haben, die sie motivieren, ihren Code richtig zu trennen.

Mögliche Abstraktion könnte sein:

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

public interface IBananaOwner
{
}

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

public class Jungle
{
}

Auf diese Weise wissen Sie, dass Bananader Eigentümer hat, aber es muss nicht sein Monkey. Es kann alles sein. Und es beschränkt die BananaMöglichkeiten des Eigentümers auf nur Operationen, die durch definiert sind IBananaOwner, was das Denken vereinfacht.

Gorillas sind keine Affen!

Abgesehen davon beantworten Sie Ihre eigene Frage mit " Wir können die gesamte Logik hinter der Funktion 'getBanana' zusammenfassen ". Ich möchte nur eine Banane, aber um sie zu bekommen, muss ich getBananaein Objekt aufrufen , z. B. eine Instanz der GorillaKlasse. Dieses Bananenobjekt enthält dann wahrscheinlich einen Verweis auf den Gorilla, zu dem es gehört, und dieses Gorilla-Objekt hat wiederum einen Verweis auf den Wald, zu dem es gehört. Also bitte ich um eine Banane, aber dahinter steckt der gesamte Dschungel.

Es ist ein extremes Beispiel und wird nicht immer so schlimm sein. Es ist jedoch nicht ungewöhnlich, dass Sie ein solches OO-System haben. Um diese getBananaMethode zu testen, muss ich einen ganzen Wald instanziieren oder verspotten.