Java Language
#2 Objects

Return to Labo.

オブジェクト指向の必要性について,
『オブジェクト指向』,Javaを学ぶ上で、必ずつきまとうのがこのオブジェクト指向って言葉だ.なんなのか,概念だけは理解しておこう.


  1. 何?
    オブジェクト指向などと言う訳のわからん言葉が余計に分からない世界を作り出している!こんなものは、概念だけ理解しておけば良いのだ〜.日本語で言えば、オブジェクト=物体の様に訳されるが、部品と考えた方が良いだろう.
    例えば、携帯電話を作るとしよう,メインの基盤とスイッチ,筐体の表裏とアンテナなどの部品を組み合わせれば、大体の形が出来上がる.だけど、例えば筐体を設計している人は、メインの基板がどういう動きをして、どの位の消費電流で、ソフトウエアはどの程度のバグを含むのかを知る必要が有るだろうか?・・無い.必要なのは、基板の寸法とスイッチ,LCDなどの位置関係,つまり、インターフェイス部分だけなのだ.この辺がオブジェクト指向のオブジェクト指向たる部分なのである.即ち、自分が作っている部分以外はブラックボックスで良いのだ.それが接触する部分だけ、きちんとルールに従ったインターフェイスが守られていれば、あとは、組み合わせるだけという考え方だ〜.
    →ソフトに置き換えてみよう.MMI部分を設計しているものにとって、LCDコントロール用のハンドラ(ドライバ)部分の動作を全て把握する必要は無い.どの様なパラメータをLCDハンドラに送れば、直線を描く,このパラメータを変えれば、文字を表示すると言ったルールだけ把握していれば良いのだ.勿論,全てを知っている方が良いのは当然であるが、システム自体が肥大化している昨今,それは不可能に近い.だから、オブジェクト指向なのだ.

  2. 弱点についても知っておこう,
    例えば、Windowsがそれである.予め、フレームやボタンなどの部品が用意されている訳だから、結果的に、それを上手く並べてやるだけでソフトは完成する.しかしながら、そのインターフェイスを無視して、直接ハードウエアにアクセスしようなどと企てた場合、たちまち共有違反やら、一般保護エラーやらの洗礼を受ける事になるのだ〜.ここに、オブジェクト指向の致命的弱点が有るのだ.ソフトウエアの設計者が、もっと高速にしたい,もっと違った形のフレームが使いたいと言う場合に、「それは、無理な相談です」となってしまうのだ.
    勿論,有る程度の自由度が用意されている場合もあるが、結局は、Windowsの言うとおりに、ソフト設計を行う必要が有るわけだ.余談では有るが、この辺は、今の会社構造にそっくりなのだ.会社が大きくなればなるほど、個人のパーソナリティは無視される.しかしながら、上司の言うとおりにやっていれば、それなりに無難なものが出来るのだ.更に、この状況を上手く利用すれば、それは、居心地の良い空間に変貌する・・・.

    とりあえず、こんなもんだろ?さっさと次に進むぞ.

  3. クラスというもの,
    オブジェクト指向のソフトウエアを設計(組み立てる)する上で避けて通れないのが、クラスという言葉だろう,大体オブジェクト指向と対になっているというか、これが有るからオブジェクト指向が成り立っているのだ.つまりは、クラス=部品そのものであるが、実体は、その部品が使用するエリア,つまりメモリの一部を示しているに過ぎない.そのエリアにアクセスする方法を備えて(規定した)カプセル化したものがクラスって事になる.

  4. クラスの生成と消滅,
    実際、これが、最終的に一番やっかいになるのだ.クラスは、生成したら、消滅させなくてはいけない.何故か? クラスは、生成すれば、それだけメモリエリアを消費する.即ち、クラスを生成して、消さないと、永久に使えないメモリエリアが、メモリエリア内に蓄積されてしまうのだ.

    〜ここまでは、大した事では無く、作ったら消せばよいのだが、面倒くさいのがここから〜

    クラスには、継承と言う考え方が有り、また、それらが入れこになって定義されているのである.実用的なクラスは、大概、幾重にも入れこになったクラスで、その本質を突き詰めて行くには、ヘッダ情報を解析していくか、膨大な量のドキュメントを読まねばならない.例えば、Windowsのプログラムで、フレーム(Window)を出現させ、その中に、スイッチを1個設けたとしよう.ここまでのプログラムは、さほど難しい事ではない.消すのもフレームを消せば、スイッチも消える構造になっている.しかし、スイッチが複数になって、場合によって、消したり出したりする場合,部品(クラス)が、スイッチ(Button)だけではなくて、Edit,Menu・・などと増えた場合、消した筈のスイッチが出現してしまう,出した筈のスイッチが出てこないなどという問題が結構発生するのだ.更に、時代はリアルタイムであり,マルチタスクであるのだ.ユーザの操作によっては、設計者の考えてもいない状態まで進行する場合もある.結局,今、どの様な状態かを、把握しながら動作するプログラムを作成する必要が有るのだ.
    まあ、当面は、この様なややこしい状況に対面する事は無いと思うし、現在のビジュアルプログラミング環境では、こんな事もシステマティックに、回避出来る様になっているから、心配する必要は無いが、一歩踏み込んで、個性を発揮しようとすると、上記問題に必ず直面するので、覚えておいて欲しい.因みに、俺などは、ある問題に、1週間以上ハマっていたことがあった.

Return to Labo. Before Next