[[BORLAND C++]]
INDEX
Section.1 Object
さて、ここからが本題となるのだが、ここでのターゲットは、Windowsのアプリケーションである。現時点で自分は、全くの素人であるので、このメモが、どの様な方向に向かうのか、最終的に、どこまで辿り着けるかは未知数だが、少しでも、自分の中で蓄積されてきた疑問がクリアになれば、と思っている。
まず、オブジェクト指向について、少々語らねばなるまい。
  • オブジェクト指向とは？
    オブジェクトというのは、物であるとか物体であるとして、自動車等を例にして説明されているが、分かりにくいと感じた方は居ないだろうか？自分は何度も同じ様な説明を受け、自分なりに解釈しようとしたが、どうしても解釈出来なかった。そこで、以前、何処かでも書いたが、このオブジェクトを、「部品」であると考えてみたところ、自分の中で疑問に思っていた事や、うやむやだった事が、割とスッキリ整理出来たのである。従って、ここでは、オブジェクトを部品と考えてまとめてみようと思う。例えば、自動車もエンジン，タイヤ，ボディ，ハンドル等の部品を組み合わせて造られている。しかし、例えばタイヤを造っている人は、そのタイヤをはめて使うホイルの設計技術や、エンジン，ハンドル等の設計まで知らなければならないだろうか？もちろん、知っている人は居るだろうし、知っていた方が良いのであるが、知らなくてもタイヤは造れるのである。知らなければならないのは、自動車の部品であるタイヤを、はめるであろうホイルの寸法と、ホイルを伝わって、どの位の力が加わり、地面に対してどの程度のグリップを発生しなければならないか？というインターフェイスの部分なのである。即ち、このインターフェイスさえ、確実に定義されていれば、タイヤを造る人は、ホイルを含む自動車の他の部分は、全く知らないブラックボックスで構わないのである。特に、タイヤ等の部品は、ホイールの系と幅が一致すれば、どの様な自動車にも使用出来る様に造られる訳で、自動車のホイルも、これに合う様に設計される訳である。また、タイヤは、すり減ったら別の部品(タイヤ)に取り替える事も出来るのだ。

  • なぜ、オブジェクト指向なのか？
    前項の車の話をソフトウエアに当てはめてみよう。構造化設計の時代には、設計者はシステム全体を知らなければ設計が出来なかった。しかしながら、現在のソフトウエアシステムは、異常なほど複雑で、システム全てを把握する事自体が、困難になっているのである。そこで、ソフトウエアについても、タイヤ，エンジン，ハンドル…の様に、それぞれの役割を確実にこなす部品単位で設計し、最終的に、これらの部品を繋ぎ合わせて一つのシステムを構築しようと考えたのがオブジェクト指向なのである。

  • オブジェクト指向を使う理由
    オブジェクト指向という考え方の理由は２つ有る。１つは、前項までに示した様に、オブジェクト単位で設計する事により、設計者が複雑なシステム全てを把握しなくて良いという事。残る１つは、独立した部品としてオブジェクトを構築する事により、他のプログラムからの不正なアクセスにより、データが破壊される事を防ぐ事が出来る事である。(データのカプセル化)
    部品単位で設計するという方法は、以前から、Ｃ言語でも分割コンパイルという方法が採られていて、これがオブジェクト指向と言えなくも無い(事実、コンパイル単位でOBJファイルが生成される)が、データのカプセル化に於いては、Ｃ言語では充分とは言えない部分が有ったのである。

  • オブジェクト指向の弱点
    オブジェクト指向を、ソフトウエア設計者の目から見ると、幾つかの弱点が明確になる。１つは、実行速度が遅いという問題である。例えば、ある変数にアクセスする場合、ダイレクトにその値を書き換え/読み出す方法が、一番速いのであるが、オブジェクト指向のクラスという単位では、変数にダイレクトにアクセスする事は許されていないので、メンバ関数なるものを使用して、変数の書き換え／読み出しを行う事になる。ここで、少なくともCALL命令と、変数の値を引き渡す為のメモリ処理が発生するので、その分のロスが蓄積されればされるほど、実効速度は遅くなる訳である。もう１つは、バグが発生した場合、あるクラスの中で発生したバグについては、そのクラスの設計者でなければ修正出来ないという点である。もし、このクラスの生き字引的存在の設計者が、何らかの理由で突然居なくなった場合、このクラスの設計思想は、この人しか知らない訳だから、この時点で開発は、完全に停止してしまうのである。他のクラスの設計者が、該当するクラスの中身まで把握していれば、その人が修正すると言う手も有るが、下手に修正すれば、他のバグを誘発する可能性も有るので、おいそれとは修正出来ないという事もある。

  • では、何故、Winodwsでオブジェクト指向か？
    オブジェクト指向の言語として、現在ではＣ＋＋，Ｊａｖａ，オブジェクティブパスカル，Ｒｕｂｙ等の言語が認識されているが、この様な言語を使わなければ、Windowsアプリの生成は不可能だと思っている方は居ないだろうか？この考えは半分間違いである。事実、Ｃ＋＋のコンパイラを使用しても、Windowsのフレームを１枚表示させる所までは、Ｃ言語だけで書けてしまうし、Ｃ＋＋特有の記述は全く必要無いのだ。では、何故、Windowsのアプリを記述する言語として、オブジェクト指向の言語が必要なのだろうか？これにも、２つの理由が存在すると考えられる。１つは、WindowsのAPI(Application Programming Interface)へのアクセスが複雑過ぎる※(即ち、Windowsシステム自体が巨大で複雑になり過ぎた)為、ユーザがプログラムするインタフェースとしては、オブジェクト指向を適用して、幾つかの単純な部品(クラス)単位で提供した方が遙かに扱い易いと言うわけだ。ここで言うクラスは、有名所を挙げれば、ＭＦＣ，ＯＷＬ，ＶＣＬ等になる訳だが、これらは皆、WindowsAPIにアクセスする為のクラスライブラリである。即ち、複雑で難解なWindowsAPIへのアクセスを、これらのクラスライブラリが、代わりにやってくれているという訳である。これについては、素人が変な値をＡＰＩにセットして、Windowsのシステム自体に悪影響を及ぼす様なプログラミングを避けるという役割が有るのも忘れてはならない。もう１つの理由は、Windowsのフレームワークが、部品を使って組み立てるという方法の方が、遙かに分かりやすい為である。例えば、１枚のフレームを開いて、ボタンを配置したければ、ボタンのクラスを生成して、位置を指定すれば生成されてしまうのだ。

    WindowsのAPIは複雑？？
    まず、WindowsのAPI(特にWin32)には、腐る程沢山のAPI関数が定義されている。何の知識も無い人が、ＢＣ＋＋をインストールして、ANSI-C++の仕様書を読んでも、CreateWindow関数は書けないだろう。また、サンプル等を参考にしていて、知っていたとしても、ボタンの使い方を知らなければ、Windowフレームに、ボタンを置くというプログラムは、CreateWindowを使うという事が分からないのである。更に、スタティックを表示したら、文字を変えるのに、SetWindowTextを使うとか…。実際問題，これらの関数のヘルプを入手しなければ、先に進めないのが事実なのだ。
    次に、関数と同じ位，沢山定義されている構造体や型宣言の存在である。WNDCLASS,HANDLE,HWND,MSG…，自分は勿論,実際にプログラム開始するまでは、こんなものは知らなかったし、Windowsプログラムに相当慣れた人でも、これらの構造体の役割と、そのメンバの役割を、全て的確に知っている人は少ないだろう。
    ここに、オブジェクト指向という考え方を当てはめると、非常に納得の行く説明にならないだろうか？この様な、難解なAPIは、クラスの内部に閉じこめてしまえば、ユーザは知らなくて良い訳である。


  • ＢＣ＋＋では？
    さて、実を言うと、ＢＣ＋＋(無償配布のCommand Line Compiler)には、このWindowsAPIをコントロールする為のクラスが定義されていないのだ。ＯＷＬ辺りならば、どこかのＣＤ−ＲＯＭから、かっぱらってくれば何とかなるのだろうが、それでは、ＢＣ＋＋を選択した意味が無いのである。では、どうするかというと、直接APIにアクセスするのである。これは、少々危険を伴うが、小規模なソフトウエアであれば、何とかコントロール出来ると思う。また、可能で有れば、クラス化を行って行けば、処理系に依存しないクラスライブラリを構築する事も出来るであろう。

余談である。
Windowsに学んだもの
最近は、当たり前になってしまった為か、Windowsのありがたみというのが忘れられがちで、技術者はLinuxだよ等という声も多いが、ここいらで、一度見直しておくのも良いだろう…と思って、ここを書いている。自分がWindowsを最初に使った時、めちゃくちゃびっくりした事が有った。同じプログラムが、IBM-PC上でも、PC-98シリーズ上でも動作しているのだ。今で言えば当たり前だが、当時は考えも及ばなかった事だったのだ。確かに、ＣＰＵは同系列のものを使っているから、マシン語レベルでは同じ訳で、ＭＳ−ＤＯＳも同様に動作するし、文字表示だけのプログラムなら何とか動作していたのだが、例えば違うハードウエアにアクセスを要するグラフィック画面や周辺ハードウエア制御については、PC-98シリーズ用に造ったソフトは、IBM-PCでは動作しないというのが普通だったからである。自分は、これを、Windowsが各ハードウエア毎にドライバを用意し、これらのインタフェイスを統一した為に出来た芸当だと理解した。グラフィック画面の例を挙げれば、アプリケーションが直接VRAMを描くのでは無く、Windowsに対して、この図形を描いて下さいと伝えれば、その要求を、Windowsが共通のインタフェイスを持つＶＲＡＭドライバに伝え、ドライバが、実際のハードウエアに対してアクセスするのである。こう見ると、Windowsというもの。これも、一つの大きなオブジェクトの固まりと考える事が出来る。即ち、このインタフェイスさえ統一されていれば、ハードウエアの事は知らなくても良い訳である。逆に考えれば、ハードウエアがバージョンＵＰされても、このインタフェイスさえ一定であれば、Windowsや、そのアプリケーションは動作する訳である。この辺りも、Windowsがオブジェクト指向の言語と相性の良い、一つの要因かも知れない。
2002/03/31
HomeSweetHome2
Ozzy's Software