ソフトウェアと抽象化技法

いつからabstraction が『抽象化』になってしまったんだろう - カレーなる辛口Javaな転職日記

めずらしくJavaBlack さんの言っていることがよくわからなかったです。「abstraction」はいつから抽象化かって元からじゃん、OOP イコール ADT じゃないよね、とかそんな風な第一印象。

うにゃぁ、これは私がよく解っていないぞ。「髪の毛のとんがった上司」が解らないで「身体的特徴で人を差別する人間いくない」とマジレスするようで格好悪い。みゅー、なんだかついてけてないのが悔しいです。

なので「よくわからないときは文章を書きながら整理するといいのよね」と OOP と抽象化について書いてみたら結構良く纏まったので、そのまんま流用です。・・・でも、結局良くわかんなかったんだよなぁ。


* * *


人間の頭は理解において、規模にたいして著しく脆弱で、簡単なものが単にたくさん集まっただけでも物事を理解出来なくなってしまいます。その人間の「理解のための道具」として、ダイクストラは著書「構造化プログラミング」の中で、

の三つを挙げました。一つ目は、順番に処理を追っていくこと、二つ目は最初のドミノが倒れることと、n番目のドミノが倒れれば n+1 番目のドミノが倒れることを証明すれば、全部のドミノが倒れると理解できること、三つ目は情報を抽象化すれば「見た目の」規模が減るために 大規模なものでも人間の理解可能な規模に押さえ込むことができるというもの。

プログラムの抽象化は乱暴に言ってしまうと、その為プログラムを分割し、切った欠片に抽象的な意味を与えて管理するような手法です。プロシージャをプログラム切り出しの箱として使い、それを使って ちょうど構造化ドキュメントの章や項と同じような 段階的抽象化された ツリーとして全体を構築する手法のことを 構造化プログラミングと言います。


「Abstractionとはこうゆうものかっ!」(ギンガナム風)として掲げられた ADT(Abstract Data Type)―抽象データ型は、データ型は実データの形式(乱暴に言えばメモリ上のビットパターン)で定まるのではなく、データに対してどのような操作ができるかで定まるのだ!なデータ型の事を言います。

しかしADTの混乱するところは、抽象データ型そのものを指すだけでなく、しばしば抽象データ型を用いてプログラム全体を抽象化する手法を指す場合もある点です。抽象データ型はモジュールのインスタンス作成可能版と見ることも出来るため、モジュールを使って出来ることは抽象データ型を使ってもできます。抽象データ型は単なるユーザー定義データ型を実現する手法というだけでなく、プログラム全体を抽象化する箱として使うことも当然可能です。

当初のC++ のプログラミングスタイルは、データ型でプログラムを構築するような、そんな感じを受けます。このスタイルは「オブジェクト指向プログラミング」と呼ばれるモノの一つであるので、「データ抽象によるプログラムの抽象化 = OOP」みたいな理解も広まっているように感じます。

一方で、Smalltalk のような メッセージとオブジェクト でプログラムを組み立てるスタイルを指す もう一つのOOP も、同様にプログラミングの抽象化技法です。Smalltalk がイメージしたのは生物の細胞のような自立分散協調系で、細胞であるオブジェクトとオブジェクト間の協調を実現するためのメッセージがあり、そのようにプログラムを形取るようなプログラミングスタイルをOOPと呼びました。ADT とは関係がありません。ポリモーフィズムは サブタイピングによるものではないですし、この方向性は行くトコまで言っちゃうと Self のように 本質的にクラスすら不要になっちゃいます。

もう一つとして オブジェクト指向の概念の発明者は誰ですか?(改訂版) - Smalltalkのtは小文字ですで sumimさんが挙げている ウィリアム・クックの PDA(Procedural Data Abstraction) ―手続きによるデータ抽象 ですが、OOP VS ADT を読んだものの私は英語が苦手なので、いまいち良く理解できていません。動的型付け言語での OOP で言う、ダックタイピングのようなものを指しているように感じているのですが、自信はないので割愛。いまいちスッキリ理解できてないのは、ダックタイピングは猫の脳内ではメッセージ指向にオートコンバートされてしまうため、違いを認識できていないというのもあるような気が(^^;。


* * *


さて、話を戻してようやく大本のネタである
オブジェクト指向を高校の必修科目に? | 日経 xTECH(クロステック)
に。実はあんまり違和感を感じてなかったのですが、読み返すとなんか変だなぁ。

物事を分析するとき、抽象度スイッチングが必要なのは、人の頭が一度に扱える物事の規模がとても小さいから。木を木と認識したまま森を認識できるほど多くの木を扱えないのが人の脳の脆弱な点だから、木を見るそのままで森を理解しようとしちゃだめだよ(それが人の頭の仕組みなんだよ)と知っているか知っていないかはとても大きい。木について考えるときは木なりの、森について考えるときは森なりの抽象レベルへといろいろスイッチしながら、それが何なのかを考える。

ITProのこの文章も、たぶんそういうことを言いたいのかなと思っていたのですが、よくよく読むと、抽象=モデルで 具象=実装みたいなことを言っているような。トップダウンアプローチな設計像なのかな?OOPボトムアップなアプローチなので、JavaBlackさんは そこら辺を突いてのことかな、とか考えるのだけれど、やはりモヤモヤっとしたままなのです。