缶詰の中の缶切り 　よく、オブジェクト指向の概要とかっていう解説にはオブジェクト指向とは ・・・ 「デ ータと処理をカプセル化したもの」・・・ なんていうオブジェクト指向の定義みたいのが 載っているけど、でも、「それがどっした」って感じなんだよね！！ 　エライ学者さんが言ってたけど、オブジェクト指向を説明するにはスペイン語(オブジェ クト指向)でスペイン語(オブジェクト指向)を解説するようなものでスペイン語(オブジェク ト指向)がわからなければ解説自体わからない、逆にスペイン語(オブジェクト指向)がわか れば解説なんていらない・・・ 「缶詰の中の缶切り」みたいなパラドクスだね・・・・・・ 　たぶん、オブジェクト指向自体、どっちかというとボトムアップ指向なので、理論から 入りたがる傾向があるのかな？ 　逆にトップダウンの目的指向で見てみると取っ付きやすいかも・・・・・・ と、いう わけで、素人の視点でオブジェクト指向って「なんじゃらほい」ってなとこをぶちまけて しもうかと大胆なことをたくらんでみました。恐いもの知らずが素人の恐いところです。

　

　

	カプセル化の目的 　最初に、「データと処理をカプセル化したもの」 という定義について考えてみました。 　データと処理をカプセル化すると、いったいどうなるのかな？ 　言葉でいうと、いたって単純なことのようだけど、その意味はいろんなところに膨らん でいるように思える 　ひょっとすると、ある世界にとっては天地が３回転するくらいのインパクトがあるよう な気がするのはおおげさかな・・・・ 　たとえば、実世界をコンピュータの世界に置き換えることをモデリングと言うようです が、従来は、これを、もともと実世界では一体となっているデータと処理をわざわざの2 つの側面（視点）に分解して、コンピュータの中に置き換え（投影し）て最終的にそれら を再び関連付けてＡＰとするという方法で行っていました。 　こうして、従来の方式は、実世界をコンピュータの世界に置き換える時に、一度、変換 してまた戻す作業を行います。そのおかげで、実世界とコンピュータの世界との間に深〜 い隔たりができてしまいますが、オブジェクト指向は視点の変換をせずにデータと処理が 一体となっている実世界をそのまま素直に表現することができると言われています。 　カプセル化の目的を素直に考えると以上のように実世界を忠実にコンピュータの世界に モデリングするということが一つといえるのかな？ 　でも、忠実にモデリングできる素質があるからといっても、その辺を理解してモデリン グしないと、せっかくの素質も活かせないということです。でも、実は、それが一番難し い問題のような気がする・・・ 　と、いうのは、実体のなかでもそれが本質を表すオブジェクトとしてふさわしいかどう かを判断するのが非常に難しいのです。 　たとえば、「納入伝票」はオブジェクトとしてふさわしいかというと、実は「納入伝票」 の中には製品名や単価など、いろいろな実体を表す属性を多く含んでいるので、オブジェ クトとしてはあまり、ふさわしくないかと思います。 　非正規化トランザクションとして、対話制御の入力フォームとして使用するには最適の ような気はします。 　「思います」としているのは、素人には判断する自信が無いからです。 　どなたか、玄人でもこの辺を判断する基準を教えてください。
	隠蔽の目的 　実は上記以外にカプセル化の意味としてまだあるのですねぇ・・・ 　それは、データと処理を一緒にするということを拡大解釈するとデータと処理の仲が良 いということなんですね。　反面、仲の悪いほかのカプセルからは隠蔽されて下手にちょ っかいを出せないということです。 　一緒にするという意味は、なにも物理的に近くに置く（実メモリ上の近くに置く）とい う意味では無いですよね！！ 　それは、いままでのように、データとデータ、処理と処理、データと処理との関係がす べて平等だったのに対し、オブジェクト指向では、「データと処理の固まり」対「データ と処理の固まり」という関係のなかで、アクセスできるデータ・できない処理、と、いう ように平等ではなくなってしまったのです。 　そして、それはインドのカースト制度のように厳格で整然とした世界をつくってしまい ました。 　それまで、ソフトウエアの世界では、アセンブラやＣ言語のように自由に何でもできる のが良いとする 風潮があったようですが、現在では、「プログラマーの勝手にはさせないぞ」といろいろ な規制をつけてきたのですよ。しかし、これによってプログラマーは反面、楽になったの です。自由という不自由、不自由という自由です。余計なことをしなくて良い分、ほかの ことに集中できるのです。個性が失われる危険性はありますが・・・。 　話がそれましたが、隠蔽により、カプセル内のデータにはカプセル内の処理からしかア クセスできなくし、外部からはカプセル内の外部インターフェースの役割をもつ処理が、 外部からのリクエストにもとづいて内部のデータにアクセスして結果を返すのです。 　なぜ、こんなことをするかというと、よくモジュールの善し悪しを判断するのにモジュ ールの強度という評価がありますが、カプセル化と隠蔽により外部との関係がシンプルに なり外部の変更・修正といった変化に対して、その影響を受けにくくなることで、モジュ ールの強度がおおきくなるのです。その結果、プログラマーは変更・修正によって影響を 受ける個所が限られるので、見つけやすくなり、また、知らない人が作ったモジュールか ら予期しないデータの変更を受けるといった不正なアクセスを防げるのです。 　したがって、カプセル化の目的を発揮するためには、実世界を良く観察して理解し、適 切にカプセル化することと、カプセル内部の本質部分を現すデータには外面的な性質を現 すインターフェース関数からのみアクセスを許すように制限を適切に課すことが必要とな ります。 　いろいろな性質をもつ複数の実体を一つのカプセルにしたり、アクセス許可を無制限に なんかするようだと、オブジェクト指向を活用できないのです。 　カプセル化の目的、意味はここら辺にある・・・はずです。
	継承の目的 　実は、オブジェクトには繁殖能力があるみたいなのです。 　しかも、親から子どもを産むのは当然ですが、なんと子どもから親を産むことができる のですね。 　さらに、普通パパとママが二人で気持ちよいことをすると産まれるのですが、パパとマ マが何人もいたりするのですから、驚きです。 　このように、複数の親の性質をもつ子どもをつくることができ、これを継承といってい ます。 　そして、子どもは親の性質の一部あるいは全部を継承し、さらに子ども独自の性質をも つことができます。 　では、なぜ、オブジェクトにはこんな能力があるのでしょうか・・ 　たしかに、親に基本的な性質をもたせておき、それを継承して子には、その子ども独自 の部分のみを付加することで、少ない労力で似たようないろんなパターンの子どもをたく さんつくれます。（特化） 　逆に、似たような性質をもつオブジェクトをたくさん見つけてきて、その中から、共通 部分を抜き出して親オブジェクトにすることで、オブジェクトの分類整理ができます。（汎 化） 　しかし、この便利な継承は使い方次第で非常に複雑でかえって面倒なことになる危険性 を秘めています。 　というのは、オブジェクト指向のデータと処理のカプセル化（つまり、一体化）のルー ルがプログラムのソース上では守られずに、いたるところに散在しているのです。 　したがって、あるオブジェクトの定義（クラス）をソース上で見たとき、実は見えない どこかの親オブジェクトの定義も含まれているのですが、継承が何段にもなると、それを 確認するのは至難なことになってしまうのです。 　せっかくのオブジェクト指向で楽になるはずが、使い方を間違うとかえって苦しむこと になるのですね。はさみも使い方で馬鹿になる・・ってことですか？
	多態の目的 　多態というのは態度が多い、つまり、親から受け継いだ性格（メソッド）をちょっとア レンジ（変更）することができることを言います。でも、本質（データの形式）は変えら れないのですね。 　この「ちょっと」というのがなかなか曲者で、完全に変えるには新たな性格を追加すれ ば良いのですが、この「ちょっと」にはちょっと深い意味があるのです。 　「ちょっと」とは親と同じ名前の性格（メソッド）でちょっと違う性格を実装すること ができ、「ちょっと」でない場合は名前を変えるのです。また、こんなことは無いと思い ますが、性格を削除（実際には何もしないように定義）することもできます。 　では、なぜこのようなことができるのかというと、親として産まれる子どもの性格が予 測できない場合にせめて性格の名前だけでも決めておきたいというような、けなげな親心 を実現するためかもしれません。 　もし、産まれた子どもが決めた名前の性格をもっていなかったら、親が代わりに面倒み ることもできますし、親が子どもの使用者にこの性格は絶対実装してよって注意すること もできます。 　また、親を汎用化でき、少ない親でいろんな子どもができるようになります。プログラ マーも親を造る手間が省けますし・・。 　クラスライブラリーとして供給するときはこの機能は便利です。 　ただし、これも使いすぎると・・・怪我のもと・・・

　

モジュールの評価 　隠蔽の目的でも触れましたが、モジュールの良さをあらわす尺度として、「強さ」とい う言葉があります。これはそのモジュールがどれだけ他の関連するモジュールからの影響 をブロックできるかを表します。 　つまり、弱いモジュールは、よそのモジュールの変更や修正の影響をもろに受けてしま いモジュールとして分離する意味を失うのです。 　そこで、オブジェクト指向は、処理とデータをカプセル化して隠蔽し、他のカプセルか らのアクセスを制限しますので強いモジュールを実現できます。 　また、オブジェクトには多態の機能があります。これはモジュールに柔軟性を持たせる ので、結果オブジェクトは強さと優しさを兼ね備えた、まるで私みたいな・・・・。 これ以上は恥ずかしくって言えません。

　

オブジェクトの自己完結 　上記のモジュールの強さと優しさでもありましたが、強いモジュールは自己完結します。 　ところが、あるシステムの中のいくつかのオブジェクトが稼動しているとしたとき、そ してそれら個々のオブジェクトは自己完結で全て自分の責任において勝手に行動したとき に、完全に自己完結だと全体としての統制はだれがとるのでしょうか？ 　不完全な自己完結であると、他のすべてのオブジェクトの動きの情報を自分の中に取り 込んで判断し制御すれば、そして、その判断ロジックが全体を統制するものであれば、個々 の判断ロジックで結果として全体の統制が取れます。 　しかし、他のすべてのオブジェクトの情報を自分の中に取り込むことは、すべてのオブ ジェクト間で複雑な関係を持つことになり、その分、他のオブジェクトの影響を受けるわ けですからモジュールは弱くなり部品としては利用価値が減少します。 　さらに、オブジェクト間の関連を決めるのはどちらかというと業務に近いレイヤであり、 この業務というのは複雑で、世の中の影響を非常に受けやすいのです。 　つまり、すべてのオブジェクトが完全に自己完結であれば、業務は実現できないし、業 務を実現するためにはちょっと弱くなければならないという矛盾がおきるのです。 ・・・・・・ 　そこで、素人はひらめいたのでした。 　統制だけを行うオブジェクトと完全な自己完結なオブジェクトの二つに分けてやれ・・ っと。 　実は、これは私がひらめいたのではなく、「堀内 一」さんが「データ中心システム設計」 （オーム社発行）で述べているのです。 　ただ、この「データ中心システム設計」（ＤＯＡ）では二つではなく、対話制御とトラ ンザクション制御、そしてデータカプセル（部品オブジェクト）の３つに分けています。 　こうすることで、部品オブジェクトは自己完結で強いモジュールに、制御オブジェクト は世の中の変化に影響されやすい業務の変更をこの部分でブロックし、システム全体に影 響が及ぶのを防ぎます。 　賢いでしょう！！

　

データは変わらない 　オブジェクト内のデータは、そのものの本質を表すというのは、ちょっと述べましたが、 世の中にある実体でも、その本質は時間が経過してもほとんど変わりません。 　時間や世の中の移り変わりで変わるのは本質を扱う業務や仕組みです。 　したがって、本質に基づいたシステムは時間や世の中が移り変わっても、そのシステム の本質はそれほど変化しません。 　ＤＯＡでは、データとＤＬＣＰのカプセルを本質とし、それを扱う部分を対話制御やト ランザクション制御の業務制御部（ＤＯＡでは業務制御部という名称は使用していません、 私が勝手に付けました）が受け持つので、世の中が変わってその本質の扱いかたが変わっ ても、システムは業務制御部分がブロックとなり陳腐化しづらい、息の長いシステムを構 築できます。 　オブジェクト指向自体には、このように本質と業務制御部の分離という考えはありませ んが、ＤＯＡと同じようにシステムを構成すれば、息の長いシステムを構築できるでしょ う。

　

多機能マシンは使いづらい 　オブジェクト指向は優れた理論で、開発者に恩恵を与えることは事実かもしれませんが、 あまりにも多機能すぎて素人にはちょっと使いづらい道具でもあると思います。 　「万人にあわせたプログラムは誰も使えない」という戒めを思い出します。 　囲碁はルールは簡単だが勝負は奥が深いもので面白味がありますが、オブジェクト指向 はルールも難しく、使い方も奥が深すぎて、面白味を超えて苦痛に思える人もいるでしょ う。 　でも、その苦痛を超えたときのエクスタシーは、それはもう、JPEGやGIFでは表現で きないほどの悦楽の世界がまっているのです。・・・・たぶん。 　私は、まだ、超えて無いのでいまだに苦痛の世界をさまよっていますが・・・。 　また、簡易言語のように、簡単だけど木目細かな細工ができなくて、便利だけど不便な 思いをする場合もあります。

　

汎用性は無駄の固まり 　部品化する一つの目的はその部品をいろいろなシステムでも使用できるようにするとこ ろにあるはずですが、自動車の部品でＴＶにも使える部品は決して多くないのと同じよう に、似たようなシステム間では流用できても、まったく違ったシステムではほとんど使え ないはずです。 　ところが、オブジェクト指向に期待する私のような素人は「そんなのは部品じゃな〜い」 なんてやたら汎用化してしまい無駄の固まりを作ってしまうのです。 　オブジェクト指向の部品は素人が考えるほど万能では無いのです。したがって、そんな に大きな期待をもたないで、せいぜいサブシステム間の共通部品くらいに押さえて、プロ トタイプ型やスパイラル型開発で部品の組み合わせを変えたり、システムの改造や再構築 時にシステム全体に波及影響が出ない利点を利用するくらいにしましょう。 　プロトタイプ型やスパイラル型開発では何回も改造、改良を繰り返してシステムレベル を上げて行くのでオブジェクト部品の利用には最適です。

抽象化は汎用性を削ぎ取る 　よく、「開発資源の有効利用」なんていう、なんとも甘い言葉を聞きますが、開発しな がら部品なんてできっこ無いと素人はかんがえるのです。 　と、いうのは、世の中の実体をコンピュータの世界に置き換えることをモデリングとい っていることは前述しましたが、実はここに落とし穴があって、実世界の実体というのは、 じつはいろんな側面をもっているのです。 　あなたの彼女だって、きっとあなたが知らない側面がいくつもあるはずですよ・・、気 を付けましょうね。お互い・・ 　そんなたくさんの側面をもった実体を全部システムの中に持ち込むのは非常に無駄です よね。 　そこで、開発者は抽象化を行うのです。この抽象化はモデリングするためにシステムが 必要としている側面だけに光を当てて必要の無い部分を捨ててしまうのです。 　プラモデルの車は、形や色はモデリングしますが、重さや大きさなどは抽象化により捨 て去ってしまうのです。 　モデリングはある世界のものを別世界のものへ置き換えることで、抽象化は必要以外な ものは見ないふりすることです。 　賢い素人はもう気づいていると思いますが、システム開発には抽象化は不可欠ですし、 部品化は汎用性が必要でこの二つには大きな矛盾があるのです。 　つまり、開発しながら同時に部品を作ってしまおうなんて、世の中そんなに甘くはない のです。 　したがって、「開発資源の有効利用」なんて甘い言葉にはだまされないで、ＣＯＭのよ うにコンポーネントのオブジェクト製造はそれ専門の餅屋に任せ、私のような素人は玄人 が作った確かな餅をおいしくいただきましょう。 　昔のひとはいいことを言ってます。餅は餅屋に・・・ 　ただし、一つのシステム内に限定して、プロトタイプ型やスパイラル型開発を行う場合、 システム全体を横断する広い範囲で抽象化することで、そのシステムではいくつかのサブ システムで共通の部品として役立つものが作れるでしょう。