ヘンなタイトルですが(^^;;)。
オブジェクト指向の話は、「プログラムの全体構成を考える」という視点からしたつもりでした。大抵のオブジェクト指向解説は、そういうことを強調しますし、実際、オブジェクト指向という発想自体からして、そういう大きな話から出てきたもののようです。でも、そんな「全体構成」とかいうような大仰な話は、相当上級者になって、長ーいプログラムを書くようになってから問題になるんで、1000行程度のプログラム(慣れる程、一括把握できるコードの長さには耐性がつく)なら、どうやったっていいといえないこともないわけです。いや、まあ、汚いコードを書く癖がつくとまずいのかな。ま、でも、小さいレベルで整理されたコードを書く、ってのは、オブジェクト指向云々よりも、そのプログラミング言語の文法上の特性の方が強烈に影響を及ぼすもんなんですね。Smalltalkなんかみたいに、文法的特性そのものがオブジェクト指向ってなら、短いプログラムに関してもオブジェクト指向の話をせざるをえませんが、C言語系とかだと変数やパラメターの使い分けとか、Mopsだとスタックの使い方、LISPとかなら関数の作り方とか、そういうところのうまさが、小さいレベルでは効いてくるように思われます。
で、なにがいいたいのかというと、その大上段からの抽象的オブジェクト指向論がどーでもよく思われるような小さなプログラムでも、クラスとオブジェクトは使うことはあるだろうと。たとえ、ハイブリッド言語であっても。じゃあ、そういうとき、クラスとかオブジェクトを、どう考えて、どう扱えば、納得がいくかと、そういう話を書いてみようと思うわけです。まあ、自分個人の実感でしかないんですが。
マネージャー
で、自分の中では、「マネージャー」というのが、一番しっくりくる感じがしています。つまり、「オブジェクトとはマネージャーである」と。カタカナ英語なのが、アレなんですが。
普通、マネージャーといわれて最初に連想するのは、私なんかの世代(中年)の日本人男性だと、学校の運動部で、雑用とか、記録付けとかしてくれる女の子、なわけです(ひとによるか)。ま、男子の場合も多いんですが、女子のマネージャーって、なんか憧れてたな。縁はありませんでしたが。あ、いや、どうでもいいことですね。これに対して、ここでいうマネージャーは、もっと英語のmanagerに近い意味です。会社とかでマネージャーというと、支配人とか支店長クラスの、かなり役が上の管理職です。「管理職」てのが、そもそもマネージメントの訳じゃないですかね。マネージメント、というと、管理、統治、支配、差配とかで、要は、マネージャーというのは、人とかモノとかを監視して、予定通り動くように上から操作する人、ですね。
もうひとつ、古くからのMacintoshユーザ(プログラマ)なら、マネージャーといって欠かすことができないのは、ツールボックスのAPI群ですね。だいたい、機能のまとまり毎に、ファイルマネージャーとか、ウィンドウマネージャーとか、名前がついていますね。この区分けは「モジュール」ということでしょうね。OSが提供してくれる入力／出力とか、いろいろな機能を、意味のまとまり毎に分類したものが、ナントカマネージャーということです。オブジェクトをマネージャーとみる発想からすると、このツールボックスのいうマネージャーは、マネージメントツールの集合体、という感じで、それ自体がマネージャー(つまり、動作主体っぽい感じ)という感じはありません。操作とか動作とか、要は、実行コードの意味内容で分ける、というのが、伝統的なモジュールの考え方だろうと思われます。Pascal系の、ModulaとかOberonとか、そんな感じですね(よく知らないので、いい加減)。オブジェクト指向ってのは、結局、機能の中心にデータを持ち込んだことで、そのデータに名前をつけて人格化し、そいつが何かをしてくれてる、っていう比喩的な見方が可能になったわけですね。ま、以前からのプログラマの方には、いわずもがなのことでしたか。
OSの方も、メニューとかウィンドウとかボタンとかは、OS側のオブジェクトとして提供します。昔は、これらは、データの構造体(レコード)として中身の定義も公開されていたので、アプリケーションの側で同じ型のデータ構造を作って、適当にデータを詰めた上で、これをシステムオブジェクトと見なしてくださいな、とお願いすることができました(らしい)。全部そうだったわけではないかもしれませんが、ウィンドウは少なくともそうだったようです。個人的には、そういうのの方が透明でいいなと思うんですけど、そうなると、システムのバージョンアップの都合で、データ構造を変更しようとしたとき、そういう自前でシステムオブジェクトを作っている全アプリケーションを書き直さないといけないことになるわけです。それで、今は、中身の構造を隠しておいて、その上に作用する関数を通してのみデータを操作するようになっています。これはオブジェクト指向の情報隠蔽の効用のひとつですね。まとまり(モジュール)毎の内部的変更がしやすくなる、というわけです。
そんなわけで、Mopsオブジェクトは、それ自体、Mopsの中でのオブジェクトであるのですが、システムオブジェクトをも伴う場合は、そのポインタをシステムから受け取って当のMopsオブジェクトの中に保管するようになっています。"NEW:"というメソッドは、大抵、そのシステムオブジェクトを獲得するためのメソッドになっています。
こういう風に考えるとき、ウィンドウとかメニューとかファイルとか、そういう対象といわゆるオブジェクトを同一視してしまいがち、ってか、自分は初めそうだったんですが、それは、あまり正確じゃありません。というのは、例えば、ウィンドウオブジェクトは確かに一回に一個のウィンドウしか扱いませんが、いったん壊して(閉じて)もう一回作ると、じつは、同じように見えても、全く異なるウィンドウを今度は扱っているのです。そういう点からいうと、ウィンドウオブジェクトは、一回に1個のウィンドウしか扱えないけれども、ウィンドウそのものというよりも、それを通じてウィンドウを操作するための窓口、あるいは、その操作のエージェント(代理人)のようなものと考える方がいいわけです。
そうすると、オブジェクトにメッセージを送るのは、ウィンドウとかファイルに直接メッセージを送って何かやってもらうってことを意味しているんじゃなくて、そのウィンドウとかファイルのエージェントにメッセージを送って、こういう風にしてくださいな、とお願いする。そうすると、そのエージェントが、ウィンドウとかファイルとかをよしなに生成・加工・廃棄等をしてくれると、そういうことになります。そういう風に、ひとつ媒介があって、その媒介がオブジェクトと呼ばれていると考えると、けっこう全体がすんなり理解できると、私は感じています。すると、オブジェクトは、対外的には、自分の支配下にある対象(システムオブジェクトやデータそのもの、つまり、オブジェクトの内部データ)を代表する地位にあり、対内的にはメッセージに応えて、その支配下の対象を適切に保守・維持・管理・変更すべく気を配っているのであって、マネージャーという感じがうまく当てはまるように思われるのです。
最終更新：2019年01月07日 22:37
