単にアイデアを書き留めるだけの文章なので、「無意味監獄」に書いておきます。
読んで意味不明でもどうにもなりません。
どうしても気になる人は分からないところの説明をメールで私に求めてください。spamの海で溺れていなければ、返事を書けると思います。
ちなみに、メモなので不確かなこと、不正確なこと、誤った用語使いなどがあり得ます。念のため。
オブジェクトの分類 §
便宜上、オブジェクトを、「関係するオブジェクト」と「実装に使われるオブジェクト」に分類する。
「関係するオブジェクト」は、同格の他のオブジェクトとインタラクションを行うもの。
「実装に使われるオブジェクト」は、オブジェクトの実装に使われるオブジェクトである。
モジュールのインポート §
モジュール化プログラミングにおいて、そのモジュールが利用する機能を含むモジュールを使用することは、インポート宣言によって明示されねばならない。
この明示によって、ソースコードのある箇所と関係を持つ可能性がある箇所の範囲が小さくなり、ソースコードの複雑度は低減される。
継承をインポートと見なす §
protectedスコープの継承の全面採用は、モジュールのインポートと同質の複雑度の低減という効能を持つ。
多重継承の肯定 §
複雑度を低減するためにprotectedスコープの継承を活用すると仮定するなら、多重継承は必須となる。
メンバ変数へのオブジェクト記述の排斥 §
この場合、メンバ変数にオブジェクトを記述することは明らかに悪い選択となる。
そのようなオブジェクトは、publicスコープの機能を公開する必要があるが、publicスコープはどこからでもアクセス可能であるので、ソースの潜在的な複雑度を高めてしまう。
単体で使われる「実装に使われるオブジェクト」の消失 §
多重継承によってクラスを実装すると、「関係するオブジェクト」は存在するが、「実装に使われるオブジェクト」は存在しない世界になる。そのようなオブジェクトを生み出すためのクラスは、「関係するオブジェクト」のスーパークラスの1つとなり、単独ではインスタンス化されない。
初期のオブジェクト指向プログラミングの常識 §
初期のオブジェクト指向プログラミングでは、以下のようなことが言われていた。
- メンバ変数にオブジェクトを記述してはいけない
- その代わりに継承を使いなさい。多重継承はそのための機能です
しかし、多重継承は問題が多いとして、このような主張は引っ込められ、逆に誤った主張であると言われるようになった。
それには理があった §
しかし、否定されたこのような主張には、明かな理があると感じられる。
明らかに私好みの理があるというのに、それに今まで気付かなかったのは痛恨といえる。
どこで足を踏み外したのか? §
象は草食動物なので、象クラスは草食動物クラスを継承します……のような現実世界と対応させるモデリングは、複雑度を低減させるという実利的なメリットを隠蔽していた可能性が考えられる。
また、再利用性の推奨によって発生したクラスの過剰な複雑さと不安定さは、複雑度の低減というメリットを相殺して有り余っていた可能性がある。
それと関連する問題として、仮想関数の混乱がある。同じクラスから継承した別のクラスを双方とも継承したとき、最初のクラスの扱いが混乱しかねない。
実験言語はありか? §
複雑度の低減という1点に目的を絞った多重継承を持つ実験言語が作れるか?
あるいは、そのために活用できるプログラム言語があるか?
ちょっとしたコーディング実験程度なら、C++で十分に検証可能か?
デメリット §
テスト駆動開発において、テストの対象となる単位が大きくなりすぎる可能性がある。
メンバ変数にオブジェクトを持たせる構造なら、そこにモックオブジェクトを入れることができるが、継承を使う場合はそのものを継承せざるを得ない。
それとも、モッククラスのような機能性を創出すべきか?
.NET Framework自身がランタイムレベルで多重継承機能を持っていないような気がするが、綺麗な実装は可能か? 実行効率は?
2006年3月14日17時50分頃追記・オブジェクトの数 §
このようなアプローチで設計されたプログラムは、生成されるオブジェクトの数がおそらくJavaやC#のプログラム(Javaタイプと呼んでみよう)と比較して大幅に減る。
Javaタイプのプログラムは、無数の小さなオブジェクトが、猛烈な勢いで生まれては消える。まるで、LISPのセルのように無造作に生まれては消える。
この多くは「実装に使われるオブジェクト」に相当する。
しかし、多重継承を前提としたプログラムでは、「実装に使われるオブジェクト」が存在しないため、オブジェクトの数は大幅に減り、生成と消滅のコストは低いものになる。
言い換えれば、効率の良い賢いガベージコレクションの恩恵が薄い。
比較的寿命が長く、サイズも比較的大きめのオブジェクトが少数存在するアーキテクチャに適したメモリ管理とは何だろう?
実は、ガベージコレクションよりも、参照カウント方式によって、リソースの寿命を常に明確に管理するアーキテクチャの方が優れているという可能性は無いだろうか?
仮にそのような可能性があり得るとすれば、Javaが持ち込んだ「いつ解放されるか分からないリソース」という悪夢から脱却できるチャンスになりうるだろうか?
2006年3月14日17時50分頃追記・メソッドの実装に使われるオブジェクト §
「実装に使われるオブジェクト」が存在しないというのはクラス定義の話であって、メソッドの実装にはオブジェクトを利用することになるかもしれない。そのためのオブジェクトはやはり「実装に使われるオブジェクト」ではあり、それは存在することになる。
2006年3月14日17時50分頃追記・名前付き継承 §
たとえば、整数クラスを用いて整数2次元座標クラスを作成するとき、整数2次元座標クラスは2つの整数クラスを継承することで、2つの整数を持つことを可能とする……のかな?
このとき、継承した2つの整数クラスを区別するためにX、Yのような名前を付けることができると、扱いやすいだろう。
このような名前を経由してアクセスすると、スーパークラスをメンバのように扱えるかもしれない。しかし、仮にソースコード上に同じように記述できるとしても、多重継承を使うと確保されるメモリの単位は1オブジェクトとなり、より少ないオブジェクト数で表現できる。
2006年3月14日17時50分頃追記・オブジェクトが少ないと良いの? §
もちろん良いのだ。
出演者が少なくなれば、それだけ出演者間の関係が減り、複雑度が低くなると言えるのだ。