カプセル化と抽象化を考える

copyright 1990
Kubo

怒涛の挑戦

• さて、今まで皆さんは、Ｃ言語を記述する際に何の考えもなしにコーディング をしてこなかっただろうか？コーディングをする作業に移れると言うことは、既 に自分が作成する部分について「言葉で説明できる」と言うことを示しているの である。
  逆の意味を言うと「言葉で説明できるまでコーディングに入るな」と言うこと だ。つまり、たかがコーディングと言えど必ず設計が伴うと言うことである。
  
  では、いったい「言葉で説明」の言葉とはなんだろうか？それは名詞である。 つまり「何々する物」と言う単位でシステムを語ることだ。
  しかしながら、このニュアンスは実際問題として難しいのも事実だが、慣れて しまえば以外と簡単に複雑なシステムでさえ設計できるようになる。
  従って本書では、Ｃ言語の立場からこのようにコーディングすれば良いと言う 例で説明する。
  設計法の詳しい方法は、信頼のできるシステム設計者からニュアンスを取得す ること。
  

＊汎用化を意識した設計・コーディング手法の徹底化

• さて、突然だがまず、「ライブラリーに登録されて来るモジュール群（オブジ ェクト）にはどんな種類のものが想定されるか？」と言う問に、まず言葉の定義 として「小さいもの」と「大きいもの」の２つに分けて考えていただきたい。
  

小さいものとは？

• 私が思うところの小さいものとは、例えばＣ言語で言うところのstrcpy等のモ ジュールを想定している。これらはたぶんコーダーレベルから数多く上がってく ると思われる。もちろんこの段階で、システム設計者は上がってくるモジュール がある程度どんな物なのか想像できているし、もしくは設計済みなので、事前に 汎用的に動作するように指導する必要がある。
  
  但し、内部設計までもを行う事は明らかにやり過ぎでコーダーのために良くな いと思われる。コーダーはコーダーなりに悩み抜いてモジュールを作成させるの がよろしい。但し、間違えを的確に指摘し、「なぜこのモジュール（オブジェク ト）ではいけないのか」を問う必要がある。明かなバグがあると言うことがらは 本説明中では論外である。
  
  もちろんシステム設計者は、モジュール群をオブジェクト単位で考えておかな ければならない。例えば数本のモジュールを１本のファイルにするのか、それと も別ファイルにするのか、ヘッダーはどうするのか、等である。以上のことは後 で徹底的に検証してみる。
  

大きいものとは？

• これに付いては、システム設計者の意志が反映したモジュール群と考える。つ まり、アプリケーション開発時に、システム全体を見渡してシステム設計者が将 来も使用可能なように企画したモジュール群である。これらのモジュール群をう まく設計できるのかどうかがシステム設計者本人の技術力の差になるので心して かかるように。
  ちなみにプロジェクトを通して「今回のプロジェクトは特殊だからな」と言い 訳して汎用化できなければ、システム設計者として進歩しない。私が思うに、ユ ーザとのやり取り以外の部分は全て汎用化できるはずである。もっと極論すると 画面レイアウト以外は汎用化できるはずである。
  

それでは一体どうゆう課程で汎用化になるのか？

小さいものに付いて…。

• 前項で記したようにシステム設計者がコーダーにオブジェクトの主旨を伝える （本当に伝えるだけでいい。少しはセンスのあるコーダーなら期待以上のものを 作成するはずである。そうゆう者はいつかシステム設計ができるし、助手として 使える。）か、コーダーから上がったオブジェクトをチェックして使えるような ら登録する。
  

　大きいものに付いて…。

• 具体的にこれが良いという方法はないのだが（なぜならシステム設計者の技術 力による度合いが強いからである）、 同一オブジェクトの作成がダブらないよ うにとか、技術力の交換のためにも事前の打ち合わせを定期的にシステム設計者 同士で行う必要がある。
  まあ、このレベルの事がわかる人達って言うのは、他人と雑談をしていても何 とかなるものである。
  
  

＊汎用化を意識した設計・コーディングとは？

• 当たり前の事かも知れないが、良い設計はオブジェクトを１つの単位として取 り扱っている。
  ところで、「オブジェクト」って何だろう？英語に堪能な人はたぶん「到達で きるような対象物、つまり、手でも意識でも触れられる物」と言うイメージで記 憶しているし、教科書的に「物・目的」と記憶しているし、プログラマーの様に 「ソース（原始ファイル）をコンパイルしてできる目的ファイルのこと」と記憶 している。
  つまり、「オブジェクト」だが、本文中では幾つかの関数（モジュール）から 成り立っている１つのソースファイルをコンパイルして出来上がったOBJ形式の ファイルと定義する。また同時に目的機能（ハッチングとかファイル転送）の１ 観念ともする。１モジュールは１目的機能の１機能である。
  
  なぜ長々とOBJの定義を行ったかと言えば、先に説明したように汎用化の一歩 は、オブジェクト単位でやり取りを行うからである。これは、目的とする機能を １つの単位としてシステムの制作者は皆に提供することになるからだ。
  言い換えれば「オブジェクトができたよ」と言って汎用ライブラリー等にちゃ んと使用できるオブジェクトを登録するしたりする。つまり、システムの制作者 はオブジェクトをどの様に区切り、どの様な目的を持っているのかと言うことが らが非常に重要になると言う事を体の一部として染み込ませなければならない。
  では、実際に注意する要因を列挙してみよう…。
  
  1.ファイル（目的とする機能）分けをどの様にするか？
  2.分けざるを得ないとして、その間の共通データをどの様に扱うべきか？
  3.再入可能とするべきか、処理速度との兼ね合いを取るか？
  4.扱うデータの制限事項とエラーをどのようにするか？
  5.第３者用ヘッダーを設けるべきか、それとも参照モジュールで済ませるか？
  6.ヘッダーを設けるとしてどこまで公開するか？
  7.オブジェクト形態はどの様にするか？（初期化−＞使用−＞解放）
  8.その他。
  

＊実例

• これからは、オブジェクト中心で物事を考える癖を徹底的に覚え込むべきであ る。オット、ずっと読み進めてきて「こいつオブジェクト指向にかぶれたな」と 思ってもらっては困るのである。今まで書いて来た事もこれからの事も「オブジ ェクト指向」とは関係ない事だと思って戴きたい。
  
  オブジェクトの独立を単にオブジェクト指向だと思うのは、言っては悪いが勉 強不足である。
  「構造化プログラム」。これは、少しシステムを設計するようになるとこの手 法の効能が痛いほど良く判ってくるし、たぶん説明もできると思う。そこまで判 れば私の言いたい事も理解できるはずである。
  
  「さらにオブジェクトの独立性を高め汎用化する」。今から記述することは、 世間で言うところの「カプセル化と抽象化」なのである。つまり、従来の言語（ 昔のベーシックは除く）で十分実現可能で、少しばかり設計の考え方を変えれば 良いのである。
  現に一般にも知らないうちにやっている人はやっているし、リストを見てもス マートである。ただ、もっと極論して徹底的に設計するのも今後役に立つと思わ れるのである。
  
  たぶんもう少しで、世間の設計法もドラスチックに変わると思われるし、その ときには前述の「オブジェクト指向」になっているだろうから、今が良い機会で はないかと思われるのである。
  なぜなら、「カプセル化・抽象化」は、「オブジェクト指向」の一部だからで ある。
  

グローバル変数を使用したオブジェクトは作成しない

• 汎用性を損なう原因は何か？それは他の部分にも影響を与えるような可能性の あるものの排除。その中ですぐに浮かぶのはグローバル変数。と言うわけで、グ ローバル変数を使用したオブジェクトは作成しないと言う結論になるのだ。
  
  そうは言っても「今携わっているシステムは既にグローバル変数使用の前提上 に構築されていて急に変えられない」ありがちなテーマである。しかし、システ ム依存の専用部分と汎用的にしたい部分とのバランスを考え、中間にクッション を設ければ必ず解消するはずである。
  但し、システム側の情報を一度どこかで中間処理にプールするという手間が必 要になるが。
  
  結論から言えば、中間処理を介しその先下の処理はグローバル変数を使用しな いような処理にするべきである。なぜならシステム依存で制作を続けていく癖が 抜けなければ、いくら内部的（アプリケーションにとって）に汎用的なオブジェ を多数製作してもそれらはオブジェクトとして専用化してしまい、とどのつまり 「汎用的なロジック（つまりこうゆう考え方をしましたと言う言い伝え）」しか 後世に残らないからである。
  これではいくら経っても後から続く者は他人のソースを見、また自分も少し違 うが似たようなソースを起こすと言ったパターンになってしまうと思われるのだ 。後継者のプログラムの勉強にはなるが、後継者はもっと違った育て型をするべ きだと私は考える。
  
  グローバル変数を使用しない」と言っても絶対ではなく、あくまでシステムの 性格に合わせて考慮すべきである。けれども「次から新規に起こすプロジェクト に付いては１００％グローバル変数を使用しない」と言う気構えでチャレンジし て欲しいものである。
  

オブジェクトがシステム使用値プール

• 以下は全て１ファイルに書かれているとする。
  
  struct _a{
  　SHORT a;
  　SHORT b;
  };
  
  struct _b{
  　SHORT a;
  　SHORT b;
  };
  
  struct _c{
  　struct _a a;
  　struct _b b;
  　SHORT c;
  };
  
  static struct _c Pool;
  /**/
  extern USHORT PoolSizeA( VOID ){ return( sizeof( struct _a ) ); }
  extern USHORT PoolSizeB( VOID ){ return( sizeof( struct _b ) ); }
  extern USHORT PoolSizeC( VOID ){ return( sizeof( struct _c ) ); }
  /**/
  extern SHORT PoolSetA( SHORT a, SHORT b ){
  　Pool.a.a = a;
  　Pool.a.b = b;
  　return( 0 );
  }
  extern SHORT PoolSetB( SHORT a, SHORT b ){
  　Pool.b.a = a;
  　Pool.b.b = b;
  　return( 0 );
  }
  extern SHORT PoolSetC( SHORT c ){
  　Pool.c = c;
  　return( 0 );
  }
  /**/
  extern SHORT PoolGetA( SHORT *a, SHORT *b ){
  　*a = Pool.a.a;
  　*b = Pool.a.b;
  　return( 0 );
  }
  extern SHORT PoolGetB( SHORT *a, SHORT *b ){
  　*a = Pool.b.a;
  　*b = Pool.b.b;
  　return( 0 );
  }
  extern SHORT PoolGetC( VOID ){ return( Pool.c ); }
  /**/
  extern UBYTE *PoolP( VOID ){ return( &Pool ); }
  
  

  オブジェクト内部の状態を返すモジュール群 オブジェクト内部のプール値は関数によってやり取りされる

  まあ、前項が一般的なコーディング例なのだが、具体的に「ああ、そうゆうこ とね」と判ってもらえばこの件はこの位で良いとする。もう少し突っ込むともっ とおもしろい事が判明するのだが、いずれの機会に説明したい。
  
  例では一つ一つのデータを丁寧に扱ったが工夫次第ではグローバル変数の参照 よりも楽になるし、速度も工夫次第だと思われる。第一システム使用値プールに 変更があってもプール・オブジェクトの変更のみでリコンパイルも済み、妙なバ グも生まないのである。
  本件は今後の研究テーマに値するのである。
  
  ※研究
  　　　構造体・共用体の定義の仕方を工夫してみよう。
  　　プール・オブジェクトのデータの先頭のアドレスをうまく押さえてみよう 。
  

ヘッダーの乱立は混乱を招く

• ライブラリー仕様書に「何々ヘッダーをリンクする事」の制限が多かったり、 中身など知る必要の無い構造体を定義したヘッダーをインクルードするなど苦痛 以外の何物でもないし、妙なバグの原因になるばかりである。
  
  また、オブジェクトの実体を良く知らない人に解放するのだから変な場所の構 造体をさわって欲しくない場合がある。常識としてさわって欲しくない（見せる 必要の無い）オブジェクト内のモジュールに付いてはスタティクを使用するがそ れ以外の部分に付いてはどうしたら良いのだろうか？
  
  関数のプロトタイプに関数宣言が必要だ。だからそれの宣言用にヘッダーが必 要になる。するとヘッダーが増えるので良くないから関数は全てショート型にす る。
  これも一理あるが、あくまでＣ言語に限れば全てのモジュールは関数であるわ けでその利点をそう簡単に捨てるのも口惜しい気がする。この件は私自身もまだ 結論がでていないが、時間があったら特殊な値を返す関数と、引き数で特殊な値 を返す関数の２つを両方とも作成するのがよいと思うのだ。
  もちろん特殊な値を返す関数のプロトタイプ宣言を含んだヘッダーを作成して …。
  でないと以下のようなコーディング例ができないのである。
  
  /**/
  extern struct _a *PointerA(){　　　　//特殊な型の関数
  　....
  }
  
  extern SHORT *PointerB(){ return( number ); } //static *number　でオブ ジェクト内部で宣言されているとする
  /**/
  extern SHORT func(){
  　struct _a *p;
  　.....
  　PointerA()->x = x;
  　*PointerA() = *p; 　//例１　関数とは入れ物を伴う。（気ずいていたかな ？）
  　*PointerB() = 1;　　//例２　これで上記オブジェクト内の*numberに値が 入る
  }
  
  関係ないが上記の構造を「プログラム内臓型」または「ノイマン式」と言う。 これを良く理解するとシステムの虚を付くコーディングが可能になる。
  
  

前項ヘッダーの事柄に関係するが、構造体はなるべく隠ぺいするべきである

• いくつかのオブジェクト群からなる特定のライブラリーの間でのみやり取りさ れる構造体（ライブラリー使用者には関係ない構造体）は、その全てのデータを 隠ぺいしても差し支えないのである。
  
  次にコーディング例を記す。
  /**/
  obj1とobj2に共通の構造体
  struct _a{
  　SHORT counter;
  　SHORT data;
  }; これを"z.h"と言うヘッダーにいれる
  
  /**/
  obj1
  #include "z.h"
  extern SHORT Init( struct _a *p ){
  　p->counter = p->data = 0;
  }
  
  /**/
  obj2
  #include "z.h"
  extern SHORT Start( struct _a *p, SHORT d ){
  　p->counter++;
  　p->data = d;
  }
  この例では、「obj1,obj2」の制作段階では「z.h」を使用しているが、もしラ イブラリー使用者にとって構造体の中身が関係ないのならライブラリー仕様書に は次のように記してもいいはずである。
  書式　　　ret = Init( p );
  引き数　　UBYTE *p;
  書式　　　ret = Start( p, d );
  引き数　　UBYTE *p; SHORT d;
  つまり、ライブラリー製作用のソースではpと言う構造体を定義していたが、 これがライブラリー使用者にとって関係ないのなら、総称アドレスのみでいいは ずである。
  pに付いてのコメントは各自で考えてみる事。以上の例では、簡単すぎてピン とこないかも知れないが、もう少し高度の使い方では絶大な威力を発揮するはず である。
  
  
  

部分的に隠ぺいする

• システムを設計していると部分的に構造体を隠ぺいしたい場面が多々ある。構 造体を公開してオブジェクトを使用させたいが実はある一部のデータは内部での みしか使用されず勝手にデータを変更されては困る場合である。以下の例でみて みよう。
  
  /* 画面制御の構造体 */
  struct _a{
  　SHORT BaseX, BaseY;　　　　//ウインドウのベース座標
  　SHORT SizeX, SizeY;　　　　//ウインドウのサイズ
  　SHORT Bc, Fc;　　　　　　　//バックと手前のアクティブ色
  　SHORT Coord;　　　　　　　 //座標系のモード
  　....
  };
  
  /**/
  ウインドウの初期化
  extern SHORT WindowOpen( struct _a **p ){
  　*p = malloc( sizeof( struct _a ) );
  }
  extern SHORT WindowSetColor( struct _a *p, SHORT fc, SHORT bc ){
  　p->Bc = bc;
  　p->Fc = fc;
  }
  
  以上の例で構造体「struct _a」は、ライブラリー制作時のものとすると、ア クティブ色以下をオブジェクト内部での使用値とし、隠ぺいしたい場合ライブラ リー公開時には以下のようにする。
  window.h
  struct _b{
  　SHORT BaseX, BaseY;
  　SHORT SizeX, SizeY;
  };
  もしくは
  struct _b{
  　SHORT BaseX, BaseY;
  　SHORT SizeX, SizeY;
  　UBYTE reserved[データ分];
  };
  レファレンス書式　　ret = WindowOpen( p )
  引き数　struct _b **p;
  ウインドウ構造体注意　　window.hを取り込む事
  
  つまり、オブジェクト作成時に使用した構造体を公開する必要無く、都合のい い部分のみを公開しても良いのである。ただし注意しなければならないのは共通 部分を構造体の先頭に持ってくる事である。
  
  応用例として次の場合も同様である。
  ※構造体の先頭に意味のあるデータを持ってくる参考
  可変型のデータ構造を定義する場合。（データＦＩＦＯにも応用できる）
  struct _a{
  　SHORT Size;　　　 //データ数
  　UBYTE data[1]; 　 //この部分のデータ数を可変にしたい場合
  };
  構造体とは先頭のアドレスとデータの始まるまでのバイト数が解っていればい かようにもなるのだ（コンパイラが知っている）。コンパイラの特性も勉強する と更に高度なコーディングが可能になるのだ。
  受けをねらって、まちがってもパブリックとかフレンドとかマクロ定義して遊 ばない事。（意味解るかな？）とにかく以上のような構造体を公開用にしておけ ば、モジュール操作以外ではアクティブ色を変更される恐れはないし、使用者に 変な誤解を招くこともなく、安全なオブジェクトとして機能するはずである。
  ウインドウの例をとれば、ライブラリー使用者に操作できるのは、オブジェク トとして用意されたモジュールを使用するか、公開されたヘッダー（構造体）を 操作するしか手はないのである。
  

再入可能にする

• 以下は一見良さそうなオブジェクトの例。
  たぶんこんなオブジェクトがあふれると思われる。それでは困るのだ。
  
  func1.c
  /***********************************************************************
  　「ある回数ループの時の座標値を得る」と言うオブジェクト
  */
  static SHORT Counter = 0;/*システム・カウンター*/
  static SHORT X, Y; 　 　 /*座標値 */
  
  /*　　　システムの初期化 */
  extern SHORT SystemInit( VOID ){ return( Counter = X = Y = 0 ); }
  
  /* 座標計算 */
  static SHORT SystemGet( SHORT c ){ return( Counter * c ); }
  
  /* ループ用関数 */
  extern SHORT SystemLoop( VOID ){
  　Counter++;
  　X = SystemGet( 3 );
  　Y = SystemGet( 2 );
  　return( Counter > 1000 ? ERROR : NORMAL );
  }
  
  /* 現在の座標を得る */
  extern SHORT SystemGetXY( SHORT *x, SHORT *y ){
  　*x = X;
  　*y = Y;
  　return( 0 );
  }
  オブジェクトをしっかりイメージしていないためこのようなコーディングにな ってしまう。たぶん今のうちに指摘しておかなければ似たようなオブジェクトが 山のように汎用化されてしまいだろう。
  しかしながら間違いではないのだ。オブジェクトの考えの違いなのだと言う事 を一言記しておこう。
  
  main.c
  /********************************************************************
  　サンプル
  */
  main( VOID ){
  　SHORT x, y, i;
  　SystemInit();
  　for( i = 0; i < 100;i++ ){
  　　SystemLoop();
  　}
  　SystemGetXY( &x, &y );
  　return( 0 );
  }
  以上の例で使用すれば一見正しそうだが、以下の場合再入を考慮していないオ ブジェクトなので誤動作を起こし、汎用的なオブジェクトとは言い堅くなる。
  
  /******************************************************************
  　サンプル
  */
  main(){
  　SHORT x, y, i, j;
  　SystemInit();
  　for( i = 0; i < 1000; i++ ){
  　　SystemInit();
  　　for( j = 0; j < 100; j++ ){
  　　　SystemLoop();
  　　}
  　　SystemGetXY( &x, &y );　 //j回後の座標を期待している
  　　SystemLoop();
  　}
  　SystemGet( &x, &y );　　　 //i回後の座標を期待している
  　return( 0 );
  }
  前項の例では「何を馬鹿な」と思うような処理だが、実際jに対するループが 関数でできていてその内部で上記の処理が書いて合ったらと考えると汎用的と言 えるだろうか？
  少なくともオブジェクト独立の精神からははずれるし、内部関数までも細かく 調査しないと恐ろしくて使えないのである。では、どのように設計するのか次に まとめた。
  
  func2.c
  /***********************************************************************
  　「ある回数ループの時の座標値を得る」と言うオブジェクト
  */
  typedef struct _tag{
  　SHORT Counter; /*システム・カウンター*/
  　SHORT X, Y; 　 /*座標値 */
  }BLOCK;
  static BLOCK Block; /*　　　システムの初期化 */
  extern SHORT SystemInit( BLOCK **p ){
  　if( ( *p = malloc( sizeof( BLOCK ) ) ) == NULL ){ Error(); return( ERROR ); }
  　return( (*p)->Counter = (*p)->X = (*p)->Y = 0 );
  }
  
  /* 座標計算 */
  static SHORT SystemGet( BLOCK *p, SHORT c ){ return( p->Counter * c ); }
  
  /* ループ用関数 */
  extern SHORT SystemLoop( BLOCK *p ){
  　(p->Counter)++;
  　p->X = SystemGet( p, 3 );
  　p->Y = SystemGet( p, 2 );
  　return( p->Counter > 1000 ? ERROR : NORMAL );
  }
  
  /* 現在の座標を得る */
  extern SHORT SystemGetXY( BLOCK *p, SHORT *x, SHORT *y ){
  　*x = p->X;
  　*y = p->Y;
  　return( 0 );
  }
  
  /******************************************************************
  サンプル
  */
  main(){
  　SHORT x, y, i, j;
  　UBYTE *p1, *p2;　　 //ヘッダーを公開する必要がない
  　SystemInit( &p1 );
  　for( i = 0; i < 1000; i++ ){
  　　SystemInit( &p2 );
  　　for( j = 0; j < 100; j++ ){
  　　　SystemLoop( p2 );
  　　}
  　SystemGetXY( p2, &x, &y ); 　//j回後の座標を期待している
  　SystemLoop( p1 );
  　}
  　SystemGet( p1, &x, &y ); 　　//i回後の座標を期待している
  　return( 0 );
  }
  汎用化と言ってもここまできちんと設計されていないと使いものにならないと いうことがわかったであろうか？そうは言っても速度の面とかである程度犠牲に しなければならない場合もあるので、そうゆうオブジェクトを設計したら一言「 再入不可能」と記しておいて欲しいものである。
  

＊最後に

• 気がついた人がいると思うが、どの例もオブジェクトを操作するアドレス（オ ブジェクト制御体）を伴っていると言う共通点があるのだ。これは何も特別な事 ではなく大型機などでプロセスが独立している場合（マルチプロセス）のメッセ ージ・キューと同じことである。
  つまり、一つの信念、「システムは突き詰めると同一的な考えに集約してくる 」と言う意見になってしまう。なぜなら、マルチプロセスの仕組みと独立したオ ブジェクト群の構築は所詮同じ事なのだ。
  メッセージ・再入可能・システム関数などなど。
  コンピュータの観念の世界は、自然現象と違い「既に誰かが構築した世界」を たどる世界なのだ。だから一般の技術者にとってゴールが存在するし、不思議な 現象は絶対に起きない。「非常に淘汰された世界」の答は一つなのである。
  
  しかしながら、それだけではおもしろくない。
  技術者である以上もっと変わっていて、うなるような処理や思想を編みだそう ではないか。

戻る