|
|
概要 |
|
|
オブジェクト指向に関するより深い理解を得るべく、また活字に慣れるべく、読み進めてみました。その読書ログをここに残します。 約20年も前の文献なので、現状と乖離している部分があるやもしれません。でも、大枠はきっと今でも同じ...と信じて読んでみます。
|
|
概要 |
|
|
|
オブジェクト指向に関するより深い理解を得るべく、また活字に慣れるべく、読み進めてみました。その読書ログをここに残します。 約20年も前の文献なので、現状と乖離している部分があるやもしれません。でも、大枠はきっと今でも同じ...と信じて読んでみます。
|
|
目次 |
|
|
0. はじめに |
この本は数式もプログラムも抜きで、とにかく図と文章によってオブジェクト指向を説くもの。専門的知識よりも、比喩や文彩などの修辞学的センス（レトリックの能力）を必要とします。
実際のソフトウェア開発では、実体論も現象論も、構造主義も機能主義も、どちらも共に必要となるようで、その旨を本の全体を通して理解できれば良いとのこと。
|
|
1. 狭義のオブジェクト指向 |
1.1 なぜオブジェクト指向か
いきなり、Smalltalkの経緯をば。子供の学習過程を研究するという目的で設計された言語で、Simula、LOGO、Lispといった言語からの影響を受けました。
前置きはここまでで、本題の「なぜオブジェクト指向か」について。
さて、なぜオブエジェクト思考かという問の答えは、現実世界をそのまま投影するということに尽きる。
...
コンピュータの中に現実世界をそのまま持ち込んで、現実世界を代替（シミュレート）するのがオブジェクト指向技術の目標なのである。
かつてのコンピュータ本位のソフトウェア開発（上から下への逐次処理）では大規模な問題に対処できなくなり、 やがて、ダイクストラらによって「構造化プログラミング」なるものが提唱されることになります。 単純な逐次処理から、その一部分を切り離して抽象化（e.g. 関数化）を施し、再利用を可能にして。 オブジェクト指向も抽象化の観点では同じようなものですが、構造化プログラミングにおける「機能の抽象化」に留まらず、「データの抽象化」を含めていたことがポイント。後の項目にて改めて述べられます。 ちなみに、これもまた後述されることですが、手続き型を否定するわけでは決してありません。結局、オブジェクト指向とて手続き的考え方を用いるのですから。
1.2 オブジェクト指向の流れ
オブジェクト指向の現状（出版当時）を、プログラミング言語、データベース、システム分析設計、分散オブジェクト環境の４視点から眺めてみます。
プログラミング言語は、データ型、データ抽象、抽象データ型を経て、オブジェクト指向へ変化してきている。
データ型の例はC。オブジェクト指向の例はSmalltalk。この両者に一応は触れたことがありますが、データ抽象と抽象データ型の例として挙げられている言語に触れたことがありません。 いったい何なのでしょうか。
例えば、「参照テーブル」という抽象データ型を定義したとする。参照テーブルには「キー」とユニークに対応する「値」があり、キーを指定することで値を操作できる。
このような参照テーブルの実装方法はハッシュテーブルや2分探索木や線形リストなどいくつかある。
クライアントコードからすれば、データ型の抽象化された属性はどの場合でも同じである。
（引用：Wikipedia 抽象化_(計算機科学)#データ抽象化）
これも引用（Wikipedia 抽象データ型）ですが、 文字列、スタック、キュー、連想配列なども抽象データ型とするよう。文字列であれば、その中身をどのようなエンコーディングで保持しようが、表示の際には関係ない（同じ表示にできる）わけですし、 スタックやキューも、配列で実現しようが線形リストで実現しようが、やはり利用時には関係ありません。とかく、この辺のことをデータ抽象・抽象データ型と呼ぶらしいのです。 で、これを踏まえた上でオブジェクト指向に流れているのだ、と。オブジェクト指向の何たるかは、後の項で理解することとします。
さて、リレーショナルデータベースがはらむ問題（平面的な表でしかなく複雑なデータを扱いづらいとか、汎化階層が利用できないなど）を解消できるらしい「オブジェクト指向データベース」ですが、 実は、これもまたピンと来ません。。。どんなものなのでしょうか。
オブジェクト指向プログラミングにおいて、オブジェクトをデータベースに格納（永続化）する方法の一つである。
...
1.オブジェクトデータベース: 従来のプログラミング言語もしくは新規に開発するプログラミング言語に、永続化の機能を追加する。
2.オブジェクト関係データベース: 従来の関係データベースにオブジェクト指向の機能（カプセル化や継承など）を追加する。
（引用：Wikipedia オブジェクトデータベース）
データベースシステムという別枠の仕組みがなくとも、永続化できさえすれば、確かに役目は果たせそう... 1.は、つまりそういうことですよね？ 2.は、例えば「PostgreSQLでデータベースの扱いを始めました」という具合。同じ「操作」を格納していては無駄が生じるので、データベースシステム自体で継承に対応し、無駄な情報の格納を避けようとするのですね。
ダメだ...細かいことに拘っていたらキリがない...（本来の目的から逸脱している!!）ゆえに、あとはザックリと。
システム分析設計においても、従来は「構造化分析設計（SA/SD）」が用いられていたようですが、それが徐々に「オブジェクト指向分析設計（OOA/OOD）」にシフトしているようです。
ただし、大切なのは「SA/SDが良い」とか「OOA/OODが優れている」などという問題ではないということ。
OOA/OODはSA/SDの上に成り立ち、オブジェクト指向プログラミングは手続きプログラミングを土台にしている。
オブジェクト指向に対して手続き型が別物なのではなく、むしろ手続き型を継承して成り立っているようなもの。上位階層を軽んずること、即ち自身を軽んずることですからね、気をつけます。
最後の分散オブジェクト環境について。
オブジェクトの自立性を、ひとりの人間に擬人化したものとみなし、協調モデルを考えていることが多い。
自分も、目の前にいる相手も、さらに周囲にいる他の人も、生きている。つまり、それぞれの生命活動は並行しているわけです。 分散環境について考えるとは、まさに舞台演劇について考えるようなもので、誰が何をした時に他の人が何をすべきかを考える「脚本作り」に相当します。 構造だけではなかなか想像がつかないですが、オブジェクト指向の擬人化を駆使すれば、割りとイメージしやすくなりそうですよね。
最近のオブジェクト指向にまつわる技術の地図を提供したので、読者の皆さん自身が立っている位置を確認できたはずである。
私は蚊帳の外にいました（笑） これから先を読み進めて蚊帳に入れるよう努めます。さて、次項からの構成は以下のとおり。
いざ、見てゆきます。
※ここから思いっきり簡略化します。本に書いてあることは本を読めば良いという話で。会得物や疑問のみを残します。
1.3 抽象データ型
...データは独立に存在することが許されず、また、手続きも独立に存在することが許されない。
俗に言うクラスメソッド（スタティックメソッド）は如何なものでしょう。もちろんクラス変数を参照している場合もありますが、 そうでない場合、手続きだけが独立していると見做すこともできそうですよね。むむむ...。
1.4 インヘリタンス
これは、上位と異なる属性や機能のみを記述する差分プログラミングである。
つまり、各々の抽象データ型には、そこで注目すべきことだけが記述されているということ。余分な情報が削られている...ゆえに理解度も向上するわけです。
インヘリタンスの面積すなわち縦軸は多様性を表している。
自分は何になれるのだろうかという問いの答えは、この多様性に当たる。
プロトタイプ（雛形）に基づいていれば、委譲によるインヘリタンスである。
「委譲」がよくわからなかったので調べてみました。
あるオブジェクトが、自分には応えられないメッセージを受け取ったとします。すると、そのメッセージを別のオブジェクトに投げる（委譲する）するのです。
「私には応えられないから、あなたが代わりにやっておいて！」という具合に。ちなみに、この委譲先を先行できるのが特徴のようです。
（参考：オブジェクト指向用語集）
そうなると、「私には応えられないから、ご先祖さん宜しく！」という部分クラスによるインヘリタンスと特に代わり映えもしないのですが... ちょっとモヤモヤ。
あと、読み進める中で「認知的経済性」という言葉に引っかかりました。これは、ある一定の努力によって得られる認知量のことを指すものだと思います。 一定の努力で多くのことを認知できるなら良好、一定の努力によって認知できることが少ないなら不良です。
1.5 ポリモルフィズム
この結合方法をメソッドサーチと呼ぶ。
こういった仕組みを実装したらば、C言語でオブジェクト指向プログラミングをすることも可能である、と言われて驚いた去年の夏（青木塾）を思い出しました。 c2oo7もc2oo8も実装せぬままですが...。
メッセージは文字列（シンボル）であり、メソッドに付けられた名前である。
今まで勘違いして使っていました。「メッセージ」と「メソッド」が同じものだと思っていましたが、そうではなかったようですね。。。
ポリモルフィズムを有効に活用するためには、やはり先人の遺産（ライブラリ）の中で、どのような名称（メソッド名）が使われているかを学ばなければなりません。 新語を生んでしまってはポリモルフィズムは死んでしまいます。だからこそ「共通な語彙を用いて包摂する共有可能性の道」を開かねばならないのです。
1.6 オブジェクト指向への準備
オブジェクト指向を実践するための事項を列挙した後、オブジェクト指向の短所（三重苦）についての言及がありました。
コンピュータの性能は当時よりも随分と向上し、このうちの上3つの問題点はほとんど気にならないはずです。 しかし、最後の「学習コストの高さ」は人間が進化しない以上どうしようにもないでしょう。こればかりは地道に学ぶしかなさそうです。
あと、不明だった言葉「ペトリネット」について。
カール・アダム・ペトリが1962年に発表した離散分散システムを数学的に表現する手法である。モデリング言語としては分散システムを注釈付の有向2部グラフとして視覚的に表現する。
（引用：Wikipedia ペトリネット）
図解でわかりやすい例があったので、記載しておきます。（ペトリネットとは http://www.infonets.hiroshima-u.ac.jp/research/petri/）
1.7 言語、環境、資産
オブジェクト指向の真価は、作成しながら整理する過程を経て、はじめて発揮されるのであって、プログラミング言語に由来するものでもなければ、環境や資産だけに由来するものでもない。
実践してナンボのオブジェクト指向。
オブジェクトとしてのソフトウェアデータベースなどが必要であろう。
これは暗にSmalltalkを指している...？
|
|
2. 広義のオブジェクト指向 |
第1章について書きだしてみて、あまり意味ないな...と実感してしまったので、端折れるものは端折ります。（もう、節の見出しも必要ない。） さて、第2章ではプログラミングという観点を取っ払い、理解や認識の枠組みとしてのオブジェクト指向について垣間見ることになります。
（つづく）
|
|
3. オブジェクト指向によるシステム分析設計法 |
（未読）
|
|
4. オブジェクト指向の評価と見積り |
（未読）
|
|
5. オブジェクト指向を支援する道具 |
（未読）
|
|
6. オブジェクト指向を支援する環境 |
（未読）
|
|
7. オブジェクト指向を支援する組織 |
（未読）