9-5. オブジェクトの管理 (1) オブジェクトの主体性を考える オブジェクト指向で一番問題となる所は、何をオブジェクトにすべきかということである。 それが分かれば、オブジェクトのイメ−ジからクラスのおおよその形を作ることができる。 しかしこれだけでは不十分である。何をオブジェクトにすべきかを考えたら、今度はその オブジェクトにどれだけの重きを置くか、見極める必要がある。 言葉を換えよう。多分作成しようとするアプリケ−ション像というのは、頭の中にある混 沌としたものである。それを色々スケッチを描いたりして、様々な機能やデ−タを拾い出 し、1つの塊を切り出す。そして、この塊に何を期待するか、その期待の大きさはいかな るものかを考える。この期待がある大きさ以上になると、これはオブジェクトだなと認め ることになるのであろう。 1つCADの画面操作を例にして考えてみよう。画面操作には絵の拡大、縮小表示や移動 といった機能がある。これらの機能を担うオブジェクトをスクリ−ンとする。またCAD には、たいがいグリッドという座標を拾う機能がついている。このグリッド機能とスクリ −ン・オブジェクトの関係を元に、オブジェクトの主体性というものを考えてみたい。こ れによって、オブジェクト間の結び付きや、オブジェクトの包含関係をより鮮明にできる かも知れない。 [1] グリッドはスクリ−ンの機能そのものであるとみなす。 [2] グリッドはスクリ−ン機 ---- 機能の一部なのだから、主体性など認める必要はない。 能の一部であるとみなす。 [3] 同上 ---- 積極的に主体性を認めても、いいのでないか。 [4] グリッドとスクリ−ンは別ものとしてみなす。 * [CASE-1] BはAの機能そのものである 注.Bはグリッドのクラス。Aはスクリ −ンのクラスと見て下さい。 class A { public: void grid_display() ; スクリ−ンの機能に、グリッドもあ void set_grid_color() ; らかじめ入っているのは、当り前で ... あると考える立場。 } * [CASE-2] BはAの機能の一部である --- あくまでも一部でしかない class A { オブジェクト b は、オブジェクトa B* b ; の中で生成しているが、特に主体性 public: をもたせない場合。b をアクセスす A() { るには、 クラス A のメンバ関数で b = new B ; 実装することになる。 b を public } 指定してもいいがそれは面白くない。 void grid() { b->grid() ; } } ; A ____ / a \ (b')がない | | | B | | {b} | \____/ * [CASE-3] BはAの機能の一部である --- 主体性を認めてみよう B* b' ; a の中で生成されたオブジェクト b をクラス B のオブジェクトのポイ class A { ンタ b' に代入する。 B* b ; public: b' はオブジェクト a によって管理 A() { されているが、どこからでも bを直 b = new B ; 接使うことができるグロ−バル・オ b' = b ; ブジェクトになる。 } void grid() { b->grid() ; } このやり方は、結構使いでがある! } ; A ____ / a \ | | B | B | | {b} ←――― {b'} \____/ * [CASE-4] BとAは基本的には別ものである class A { b はクラス A の外で生成されてい B* b' ; る。a の中でも、b をたまには使っ public: てみようかな−という場合。 A( B* b ) { b'= b ; } } ; A ____ / a \ | | B | B | | {b'} ―――→ {b} \____/ (2) オブジェクトの結び付きの種類 オブジェクトは普通、オブジェクトそれ単体で存在しているよりも、互いに関連し合って 存在している場合の方が多いのでないだろうか。単純な例として、線分オブジェクトとそ れを構成する点オブジェクトの関係を元に、どのような結び付きがあるか列挙してみよう。 実際のアプリケ−ションで、どのケ−スを採用するかは、それぞれのオブジェクトにどん な役割を持たせるのかによって決まる。オブジェクトの役割を考えるには、ここに挙げた オブジェクト間の結び付きや、先に述べたオブジェクトの主体性を検討することになるだ ろう。 * {point} / class Line { class Point { [a] {line}* 双方から参照できる Point *a,*b; Line *l ; \ } } * {point} * {point} / class Line { class Point { [b] {line} line から point を Point *a,*b; ナシ \ 参照できる } } * {point} / {point} * class Line { class Point { [c] {line} point から line を ナシ Line *l ; * 参照できる } } \ {point} _____ / \ | {point}| line オブジェクトの class Line { [d]|line | 中に point オブジェ Point *a,*b ; | {point}| クトを内包する } \_____/ [e] {Line} line と point の結び付きを class LINE { / | \ 管理する Line オブジェクト Line* l ; * ↓ * を用意する場合 Point* a ; {line} {point} {point} Point* b ; } 9-6. オブジェクトの保存について (1) オブジェクトをファイルにセ−ブする アプリケ−ション内のオブジェクトを、ファイルにセ−ブしようとするとそう簡単にはい かない。C言語で、ポインタを用いたデ−タ構造を作成した経験のあるプログラマならば、 分かると思う。ポインタで要素を結び付けるというデ−タ構造は、そのままファイルには 落とすことができない。そのため、ポインタに何らかの番号付けをして、ファイルにセ− ブし、ロ−ドする時には反対に、番号からポインタに変換してやらなければならない。通 常ポインタから番号にするには、要素はリストで連結しているので、その連結順に番号付 けする場合が多い。 C++のオブジェクトの場合、番号付けしたあと何をファイルに入れるべきか。オブジェ クトはデ−タと関数を持っているが、関数はファイルに入る訳がない。そうなると、デ− タとオブジェクトの識別名ということになる。これはC言語の構造体をセ−ブするのと似 たようなことになる。 [クラス定義の例] [アプリケ−ション内のオブジェクト] [ファイルでの状態] ----------------------------- ____________________ class Point { | 1 2 3 | |Point int x,y ; | | |10,10 Point, Line が ... | {point}→{point}→{point} | |Point オブジェクトの } ; | ↑ * ↑ * | |20,20 識別子である。 | | / | / | |Point class Line { | |/ |/ | |30,30 Point *a,*b ; | {line} → {line} | |Line int color ; | | |1,2 .... | 1 2 | |white } ; ----------------------------- |Line line の番号付けは、 |2,3 この例では関係ない。 |red オブジェクトの識別名は、即ちクラスの識別名でよい。1つのクラスから何種類かのオブ ジェクトを生成する場合がある。先に例示した Circle_Arc という共有クラスがそうであ る。ファイルからデ−タを読み込んで来て、オブジェクトを生成する際、オブジェクトの 種類分けはコンストラクタに任せればよいことになる。 (2) OODBの利用 またまた新しい用語が出てきました。OODBとは Object Oriented Data Base の略で ある。RDB( Relational Data Base ) につぐ、 新しいオブジェクト指向型のデ−タベ −スである。 簡単に内容を言ってしまえば、上の話でアプリケ−ションのオブジェクトをそのまま保存 する道具であると言える。いちいちファイルにデ−タを変換してと、煩わしい処理をしな くても済んでしまうのだから、非常に便利である。OODBを使うと、クラスからオブジ ェクトを生成すると同時に、保存できるようになっているらしい。現在、有力なOODB ソフトは 『ObjectStore』である。どうも今、新しいCADを設計している企業はC++、 Motif、そして『ObjectStore』の組合せが流行のように見受けられる。他にも幾つかソフ トはあるのだが、あまり『ObjectStore』以外のソフトの名前は耳にしないし、 宣伝もし ていないようである。 ただ気をつけた方がいいことは、5〜6年前にRDB全盛の時代があった。今でもまだ過 去のものになった訳ではないが、Empress, Oracle, informix 等々、実にたくさんあった。 どの雑誌を見てもRDB、RDBと吹聴し、どんなすごい機能があるのかと思ってしまっ た。4GLとか帳票作成ツ−ルとか周辺ソフトも、すごく魅力的に見えたものだ。その中 の1つを買ってみた。東京まで泊まりがけで講習も行った。その結果、何がRDBだ、た だのデ−タベ−ス・ソフトじゃないか。Relational と言うから、 てっきりC言語のポイ ンタ構造のようなデ−タを扱えるのかと思っていた。結局のところ要素に番号付けして管 理するわけで、今時こんな古臭いことを、 でかでかと宣伝しているのかとびっくりした。 4GLなんてものは、全っく子供だましに等しいもので、とてもや実務で使えるような代 物ではなかった。その4GLの講習で教わったことは、termcap の使い方だけだったよう に記憶している。もっとも大ぶろしきを広げた宣伝を、鵜呑みにしてしまった方も悪かっ た。早い段階でRDBなんてこんなものだと、認識することが必要であった。 OODBもどうも、ここら当りがうさんくさい所があるのでないか、一応疑ってみた方が 懸命である。OODBはオブジェクト指向プログラムの魔法の玉手箱ではない。これを使 うと格段にプログラミングが楽になるとか、オブジェクト指向プログラミングする場合に は、必ず必要であるというものではない。 -------------------------------------------------------------------------------- OODBは、アプリケ−ション実行時のオブジェクトを保存するだけのものである。 -------------------------------------------------------------------------------- 今のところこんな風に理解しているのだが、例えばオブジェクト指向は知識表現に向くと 言われているので、OODBを使うと Lisp などよりも簡単かつ明瞭に知識を表わせれる とか。あるいはOODBは最近できたものだから、デ−タ検索や一覧表示するのに Motif などを用いた使い易いGUI環境でできるとか。termcap はやめてもらいよね。ともかく 金額に見合うだけの操作性と機能を期待したい。総じてEWS用のソフトは高すぎる。バ −ジョン・アップすると、すぐ動かなくなるし、困ったもんだ。 [参考]アプリケ−ションが終了しても、消えずに残るオブジェクト(デ−タ)を、永続オ ブジェクトと言い、消えてしまうオブジェクトを、揮発オブジェクトと言う。 永続オブジェクト - persistent objects、揮発オブジェクト - volatile objects 9-7. GUI( Graphical User Interfase ) をどう使う (1) GUIの現状と問題点 * C++に限らず今後アプリケ−ションを作って行く上で、避けて通れないのが、ウィンド ウ環境下のGUIプログラミングである。 これからのプログラマは Motif を使っていか なければならない。幸いなことに SUN のユ−ザは OPEN LOOK がなくなったのでよかった。 一説によると、Motif を理解して使えるようになるまでに半年から1年かかるという。こ れはたまらない。しかし小生自身やってみて妥当な線だと思う。ともかく大変なのである。 C++よりもめんどうであることは間違いない。 そこでこの負荷を軽減しようと、GUI構築ツ−ルなる便利なものが、ここ4〜5年前か 一杯でてきた。果たして使えるのだろうか。答えを言ってしまおう。GUI構築ツ−ルは、 ビジネス向けには多分十分使える。しかしエンジニア分野、特に機械設計用CADなんか には、対応が難しい部分が出てくる。 どういうことかと言うと、イベント・ドリブンな制御方法に問題がある。メニュ−のボタ ンを押したら、それだけで何々が働くと言う処理はいいのだ。つまりボタンと処理が1対 1対応する制御は、イベント・ドリブンそのものの制御である。しかしCADの様に、線 分1本描くにも2回画面に対しマウスをクリックしなければならないような場合、単純な イベント・ドリブンな制御では対応できないことになる。 また、マウスを2回クリックする間に色を変える、レイヤ−を変えるなど割込処理が入る かも知れない。益々イベントの制御がややこしくなる。結局GUI構築ツ−ルが使えるの は、メニュ−の設計だけであり、 細かなイベントの制御は Xlib や Motif をコ−ルする プログラムを書くハメになる。 * イベント制御部分は自分で何とかやるとして、メニュ−設計だけでも楽にやろうじゃない か。それも一案である。一杯GUI構築ツ−ルは出ているから選り取り見取りかと言った らそうでない。C++対応になっているのは、4〜5年前の時点でほんの1、2本である。 そして高いときている。現在でもにたようなものだと思う。 もう一つ問題がある。構築ツ−ルの仕様を良く見ると、独自GUIとか各種GUI風対応 とか書いてある。単に Motif 対応と記しているものでも、実際はどうか分からない。 本 当の例えば Motif 対応というのは、画面設計した結果が Motif のコ−ドに落ちるもので ある。ディスクに Motif のライブラリがインスト−ルされていなければ、 稼働しないも のである。 独自GUIは Motif でも OPEN LOOK でもない、勝手に作ったものである。GUI風対応 は、スタイル・ガイドに準拠していると言うことであって、 例えば Motif そのものを使 っていると言うことではない。それらしい画面をエミュレ−トしているわけである。各種 GUI風対応のソフトには、それは素晴しいものがある。しかし、いったんこうしたソフ トでGUI部分を書いてしまうと、そのソフトから抜けられなくなってしまう。そこをど う割り切るか、問題はそこである。 * スタイル・ガイドという言葉が出てきたついでに、ひと腐り。Motif にしても OPEN LOOK にしても、そのスタイル・ガイドというものがある。スタイル・ガイドはGUIのふるま いは、こうあるべきだと言う一種の思想であり、哲学である。スタイル・ガイドを記述し たぶ厚い本が出たりしていて、まるで Motif を使うには、 これに準拠しなければならな いかのような錯覚に陥いる。 そんな本を読んでいる暇などはない。プログラムを飯の種にしているソフトハウスならい ざ知らず。そもそもEWSというのは、工場にいるエンジニアのために生まれてきたので はなかったか。エンジニアが気軽にプログラムし、自分のワ−クスペ−スとするコンピュ −タのはずだった。どうもウィンドウ・システムとGUIがその自由を奪った元凶のよう な気がしてならない。 * まとめ GUI構築ツ−ルは限界がある。細かなイベント制御もしたければ、 MotifもXlibも XToolkit も結局勉強しなければならない。 (2) GUI構築ツ−ルの種類 少しここでの内容は古くなってしまった。93年当時の資料である。最新情報は各自調べ て頂きたい。価格は開発用であるとか、ともかくUNIXマシ−ンでの、最初の1本の購 入価格を万円で示す。製品名の項の [C++] は、C++で開発できることを示す。 特に書 いてないのはC言語用である。各種GUI風対応と言うのは、例えば Motifでは、そのス タイル・ガイドに準拠していると言うことであって、Motif を使っていると言うことでは ない。 Motif対応 : M OPEN LOOK 対応 : L デ−タベ−ス対応 : D オブジェクト指向 : O フリ−ソフトウェア : F 独自GUI : I 各種GUI風対応 : V ( MS-Windows,Motif,OPEN LOOK など ) [各種GUI構築ツ−ルの一覧] 製品名 |特徴 |価格 | 適用機種 | 販売元 --------------------|-----|-----|--------------|--------------------------------- Open Interface | V | 290 | 各種 | (株)ニュ−ロン・デ−タ・ジャパン WNDX [C++] | V | 65 | 各種 | (株)リンクス・コ−ポレ−ション OXlib V2.5 | V | 150 | 各種 | (株)オ−ク --------------------------------------------------------------------------------- X-Mate | I | | 各種 | (株)フジ・デ−タ・システム Easy Window | I | 12.8|SUN,各種予定 | (株)フライト --------------------------------------------------------------------------------- EASYWIN for SunOS | M | 150 |SPARC station | DEC Interface Archtect | M | |HP9000 (HP/UX)| YHP UIM/X V2.0 | M | 95 |SPARC station | (株)アステック X-Designer | M | | 各種 | 丸文(株) TeleVIP | MO | 70 |オムロン AV | オムロン・デ−タゼネラル ezX V3.2 | M | 45 | 各種 | (株)ライフボ−ド TeleUSE | M | | 各種 | 住商エレクトロニクス(株) --------------------------------------------------------------------------------- INGRES/Windows4GL | VDO | | 各種 | (株)イングレス・ジャパン ixla CARD | MLD | | 各種 | シ−アイテクノセ−ルス(株) SyclopsΠ | MLD | | 各種 | (株)アイザック Tippler | LDO | |SPARC station | 日本ユニシス(株) --------------------------------------------------------------------------------- ET++ [C++] | IO | F | 各種 | Zurich 大学とスイス・ユニオン InterViews [C++] | IO | F | 各種 | スタンフォ−ド大学 銀行 --------------------------------------------------------------------------------- * Open Interface、WNDX などは Windows にも対応していて、 プログラムもUNIX用と共 有できるらしい。パソコンの DOS/V の価格やメモリ、ディスプレイ解像度などを考えると、 UNIXをホストにネットワ−クで DOS/V パソコンを接続する使い方は、非常に有効にな ると思われる。UNIXのEWSだけで、ネットワ−クを構成するやり方は、 これからは 一考を要するかも知れない。注.93年当時の考察である。 * ET++ はアプリケ−ション・フレ−ムワ−クという考え方で、GUIプログラムを作成する らしい。GUIのメニュ−の雛型があってそれを元に作成するということらしいが、 かな り使うのに難しいようである。 * Interview はC++によるGUIのクラス・ライブラリと言うことである。 結構使われて いるらしいが、実際見たことがないのでよく分からない。 * Tippler は(株)野村総合研究所と日本ユニシス(株)が共同開発した。 プログラム作成には、 オブジェクト指向言語 "UNISCRIPT" を用いる。マルチメディア対応、デ−タベ−ス対応に なっていて、S-PLUS,SYBASE,ORACLE,informix のクラス・ライブラリが用意されている。 * UIM/X の開発元は、カナダの Visual Edge Software 社である。 Interface Archtect の開発元は、HP 社と Visual Edge Software 社である。 X-Designer の開発元は、V.I.CORPORATION である。 * 海外の雑誌を見るとC++で使えるGUIが、まだまだ色々紹介されているようである。 ObjectViews、Quest Windows Corporation 社など。