オブジェクト指向を動物の例で説明するのは有害ではないか

オブジェクト指向の説明で、生き物を使った例を時々見かける気がします。こういうやつです：

interface Animal {
    ...
}
class Dog implements Animal {
    ...
}
class Cat implements Animal {
    ...
}

こういう 「生き物のように感情移入しやすい対象」を例として使うとプログラミング技法の本質を見誤るのではないか？ という話をします。

カプセル化

多くのクラスベースオブジェクト指向言語は、アクセス修飾子によってメンバーの公開範囲を制御できます。カプセル化というやつです。

class User {
    public String name; // 公開
    private int hidden_info; // 非公開
}

さて、publicなメンバーが誰でも見られるのはいいとして、privateなメンバーの公開先はどうあるべきでしょうか？候補は次の2つとなるでしょう。

1. 公開範囲は「自分だけ」つまりprivateメンバーを触れるのは this/self 経由のみとする。
2. 同じクラスであれば他のインスタンスのprivateメンバーでも触れるものとする。

クラスベースのオブジェクト指向を学んだ者であれば誰もが考えたことのあるこの疑問に、あなたはどう答えますか？あるいは、あなたが新しくプログラミング言語を作るならばprivateメンバーのアクセス範囲はどう設計しますか？

オブジェクトに感情移入する人であれば、「自分だけ」と答えるかもしれません。ホモサピエンス同士であっても私物を他人に無遠慮に触られると嫌ですからね。しかし、現実のプログラミング言語を見ると、privateなメンバーは同じクラスであればインスタンスに関わらず参照できるものが多いと思います。

カプセル化は何のためにあるか

そもそもカプセル化は何のためにあるのでしょうか？理由はいくつか挙げられるでしょう。

一つは「型の不変条件を守るため」です。型の不変条件が守られているかプログラマーがチェックする時、メンバーがpublicであればプログラム全体からそのクラスを触る箇所を探してチェックしなければいけません。一方、メンバーがprivateであればチェックする範囲はそのクラスの実装だけで済みます。

別の理由として「変更時の影響範囲を抑える」が考えられます。複数のパッケージを利用する開発の場合、一つのパッケージの一つのクラスの実装の詳細を変えたために他のパッケージが壊れた、ということになると厄介です。「バージョン違いで変わる可能性のある実装の詳細」に触れるのは自分のパッケージのみに制限しておけば、下流のパッケージを壊す心配がなくなります。

いずれにせよ、 カプセル化をする目的はプログラマーがコードを管理しやすくするため です。 決して「オブジェクトに自我があって、その私有物を尊重するから」ではない のです。

そして、この原則に立ち返れば「privateの対象がクラスという単位であること」に深い必然性はなく、「同じモジュールのみから参照可能」「同じパッケージのみから参照可能」という修飾子があっても良いと思えるでしょう（実際、言語によってはそういう修飾子があります。C#のinternalなど）。

オブジェクトに感情移入させるような教材は有害ではないか

「オブジェクトに自我はない」。当たり前ですね。プログラミング言語のオブジェクトなんてメモリ領域とメソッド（振る舞い）の組み合わせでしかないのですから。自我があるのはコードを管理するプログラマーです（AIがコードを管理するようになったらどうするのかという話はここではしません）。

しかし、この「当たり前」を初学者は「当たり前」と思えるのでしょうか？オブジェクト指向の教材では動物クラスや感情移入しやすいクラスを使ったミスリーディングな説明をしていないでしょうか？

というわけで、この記事のタイトルの問題提起なわけです。

（セキュリティーの話題だと複数の主体（攻撃側 vs 防御側）が絡んできますが、それはプログラミング言語の機能とは独立する問題なのでここでは扱いません。）

なお、Rubyでは

この記事の主張に反し、Rubyではprivateを触れるのは「自分のインスタンスだけ」のようです。私よりMatzの方が「オブジェクト指向」というものをよく理解しているに違いないので、きっと私の「オブジェクト指向」の理解が足りないか、あるいはRubyでは自我と羞恥心のある本物の「オブジェクト」を作れるのでしょう。そういうわけで、私の記事の主張は「オブジェクト指向半可通が書いたもの」として話半分で聞いてください。