ジョーアームストロングによるバナナモンキージャングルの問題を説明するサンプルコード[終了]

仕事中のコーダーの本で、ジョー・アームストロングは次のように述べています。

再利用性の欠如は、関数型言語ではなくオブジェクト指向言語で発生すると思います。オブジェクト指向言語の問題は、それらが持ち歩くこの暗黙の環境をすべて持っているためです。バナナが欲しかったのに、バナナとジャングル全体を持ったゴリラが手に入れた

ここではあまりわかりません。問題がバナナを取得することである場合、関数 'getBanana'の背後にあるすべてのロジックをカプセル化できます。猿とジャングルはこの文脈にどのように関係していますか。誰かの書き込みがあるという事実を証明、と言う、方法を理解しやすくして、問題を説明するコードスニペットでしたBananaオブジェクトが必要とするMonkeyとJungle、開始されるようにしてくださいオブジェクトを？

彼は、実際のOOPプログラムの大部分は懸念の分離を尊重していないという事実をほのめかしています。たとえば、次のクラスを使用できます。

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

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

public class Jungle
{
}

あなたが使用している場合はBanana、それも依存する推移必要があるMonkeyとJungle。

しかし、これはOOPの問題であり、その機能的なスタイルにはどういうわけかないことに厳密に反対します。これは、正しい抽象化の導入により、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方法をテストするには、フォレスト全体をインスタンス化、つまりモックする必要があります。