>新人はさしたる仕事もなく、昨日もオブジェクト指向のサイトを転々としておりました。
ああ、それはうらやましい。
戦力として配置されるとだんだん勉強の時間も削られてくるものですし、
さらに年を食うとろくにコードも書かせてもらえなくなるのがこの業界ですので。
> 継承：共通処理（親）をベースとして差分を子に付け加える。ライブラリを
> includeするのと逆の発想。
うーん、これはまさに(最近評判があまりよろしくない)実装継承ですよね。
以前、この辺のスレッドで議論したことがあります。
http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=270
この中で出ているoo-squareのリンクは、現在切れていますがこっちです。
http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/thread.html
よく使うメソッドをスーパークラスに置いて、なんてことをやっていると、
http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/4468.html
| 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」
| と化していることが多いようです。
なんてことになってしまう。それよりはむしろ、
http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=276&range=1
| 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」
のほうが実際の使いどころに合っていると思いますが、こうなるとインタフェースと
一緒になっちゃうんですよね。実際、「継承なんかどうでもよくてインタフェースこそが
本質なのだ」と言う人もいますし。
じゃあ継承なんかなくていいのかというとそうでもなくて、実際私も使うというのが
ややこしいところ。「継承とインタフェースのどっちを使えばいいんですか?」というのは
FAQですが、私はこれはもう単純に
・データメンバがメインの構造体的なクラスにフィールドを追加するなら継承を、
・それ以外はインタフェース
でいいんじゃないかな、と思っています。
> 隠蔽：見せたくない処理はlocal変数、local関数にて実装する。
これは実態としてまさにそうだと思います。
よく「その『オブジェクト』だけが知っていればよいことはprivateにするんだ」と
オブジェクトごとに丸を描いたりして「カプセル化」としている説明がありますが、
言いたいことはよくわかるものの、C++でもJavaでも実はprivateは
「別のクラスから見えない」だけで「別のオブジェクトから見えない」のでは
ないんですよね。
これを、単にC++(およびその派生言語)が腐っているとか実用上の妥協だとか
言うことも可能ですが、私はこれを「privateというのは他の『プログラマ』に
対する隠蔽なのだ」と考えてしまってよいと思っています。
> 多態性：引数に基づき、サブルーチン側でif～elseで処理分岐する。
> またはincludeを変える。
「またはincludeを変える」のほうは良くわかりませんが、1行目は、用途としては
そのとおりです。よくある図形(Shape)の描画ルーチンの例のように、
ポリモルフィズムを使うことで、プログラムからswitch caseを排除できます。
Cにはそれがないばかりに巨大なswitch caseを書いてる例：
http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/7.html#693
ポリモルフィズムにおいて、一見単なる実装詳細に見えるけど実は結構重要なのは、
サブクラスを追加しても、呼び出し素(switch caseに相当する部分)再コンパイルの
必要がない、ということですね。だからAppletを継承したクラスを作れば
すぐにブラウザで実行できるわけで。
> マルチプルインスタンス：サブルーチンをメインの実行状況によって任意に
> （動的に）増やせる。
うーん、これはどうなんでしょう。オセロの例で言えば、Boardをいくつnewしても、
put()というルーチンは増えないと思うのですが…
「メソッドはインスタンスに付属している」というイメージからすると、
一緒に増えると考えることもできるのかもしれませんが。