続々間違いだらけのオブジェクト指向

http://itpro.nikkeibp.co.jp/article/COLUMN/20060413/235287/

先方のオブジェクトに「処理要求と最低限必要な情報を送って,後は先方のオブジェクト内部での処理結果を受け取る」といった方法をとるしかない。

一体,何を言いたいのやら.
こういった「実行モデル」*1は,理解し易さや扱い易さ,実現可能性から決めるもので,「本当はやりたくはないが,誰かに強制されたのでそのようにする」というような類の物ではない.

「なぜ関数呼び出しやシステム・コールといった,コンピュータらしい用語を使わないのか,オブジェクト指向入門者がもっともぶつかりやすい疑問だ」

「コンピュータらしい用語」?どこが?*2

おそらくは「私が最初に学んだ言語/環境/汎用機では,関数呼び出しやシステムコールなどの用語が使われていた.」というような理由で,それらが「コンピューターらしい用語」として刷り込まれているだけだろう.まるで生まれてすぐにオモチャの機関車を見たために,それを親鳥と思ってあとを付いていく雛鳥のようだ.

なぜクラスが必要なのかと言えば,現実の物事を模する上で必須だからである。

間違った説明だね.そもそもOOPは「現実の物事を真似する手法」ではない.

人間は無意識のうちに,物事をグループ化して考えるものだ。「受注伝票」,「発注伝票」と聞けば,自動的に「これらは『伝票』という大きなグループの一種なのだな」と思い浮かべるはずだ。この例では伝票がクラスである。

これはたとえ話としては許されるが,OOPの説明としては間違いである.何がクラスになり何がインスタンスになるかは一概には決まらない.「伝票」というインスタンスを作るかもしれないし,「受注伝票」というクラスを作るかもしれない.

また「グループ化を表現するためにクラスが存在する」と間違って覚えてしまうと,それを表現するために多重継承が必要だと誤解する恐れがある.これは極めて危険なやり方だ.

オブジェクト指向における「抽象化」とは,このような考え方を指す。抽象というと何となく「物事をあいまいにする」印象があるかもしれないが,むしろ逆である。共通点を見いだして,よりクリアに物事を見ようとしているのである。

...とにかく,素人にはこのようなやり方を絶対に真似しないことをお奨めする.

おそらく書いている人は何にも分かってないので,論理の流れが支離滅裂になっている.

クラスと裏腹の関係にあるのが「継承」だ。(中略)継承はクラスと逆の考え方をしていけば理解しやすい。

以下同文.

継承には,プログラミングにおける現実的な利点もある。継承を使うと,プログラムの大半は既存のコードを使い,足りないコードだけを新たに書き足す「差分プログラミング」が可能になる。

「継承とポリモフィズムを差分プログラミングの道具」とする考え方は既に一世代ほど古い*3.詳細はGoF参照.この記事は世に出てくるのが10年は遅かったようだ.

オブジェクト指向は人間にとって自然な考え方」。この視点に立てば,その他の用語も理解しやすい。

理解したつもりになっているだけで,実は何も分かってない.初心者には,こういうやりかたは絶対に真似しないことを強くお奨めする.

複数のクラスの性質を引き継ぐ「多重継承」を備えている点も,COBOL2002の特徴である。(中略)ただし,多重継承には善し悪しがある。多重継承を使えば多様な処理を実現するシステムを開発しやすくなるが,一方で,システムの構造(クラス間の関係)が複雑になりやすいという危険性をはらんでいるからだ。

もし,COBOL開発者がこれを使うことになっとしても,多重継承は絶対に使わないように.

*1:UMLモデリングなんかのモデルとは,全くなんの関係もないので念のため.

*2:「関数」なんて数学用語だと思ってたな.昔は.
ガーベッジ=コレクションやプロデューサー=コンシューマー,ミューテーター,オブジェクト=オリエンテッド=コンピューティングなら,この人の言う「コンピューターらしい用語」なのかな?

*3:「差分プログラミング」は今でも使われている.だが「継承=差分プログラミング」という捉え方は,少々危険すぎる.