問題２．１４（問題タイトル：下位モジュールが不安定な場合）

1.問題

2.解答・解説

• 対処しても結局無駄になることも多いです。まずは、本当に必要か良く検討しましょう。
  
  
• まだ作成されていない下位モジュールを想定してインタフェースを作るのは本当に大変です。後になって、「あ、これも必要だった」なんてことにならないようにするのは至難の業です。
  どうしても、という場合、すでに不安定な下位モジュールに対してのインタフェースを定義しているシステムやライブラリを参考にするのが良いです。
  例えば、以下があります。
  
  • JavaのJDBC（DBを作っているベンダがこれの仕様に合わせ、JDBCドライバを作っている）
  • CORBA(分散オブジェクトの規格。Javaならorg.omg.CORBA.ORBクラス。これもCORBAのベンダが仕様に合わせ製品（J2SE付属のCORBA、VisibrokerやOrbixなど）を作っている。)
  • 一方向ハッシュ関数（Javaならjava.security.MessageDigestクラス。OpenSSLの該当関数もそうです。）
  • 暗号化（※一般に、一方向ハッシュ関数や暗号化処理を使うプログラムは、後になって使用したアルゴリズムが破られて使えなくなっても、作成したプログラムの再コンパイルなしに対処できるような設計にする必要があるがあるため）
  • ファイルIO（ストリーム）（方式（ネットワーク、ファイル、Zipファイルなど）相手がなんであろうと意識せず、使えるようになっている。）
  • OSGi（OSGiは規格です。これに合わせ、ベンダが実装します。）
  • Itron（OSの仕様です。例えば、これを実装したものとして、TOPPERSやHOSがあります）
    ※ちなみに、だるまは仕事の関係でμItron4.0およびμItron4.0/PX仕様の仕様書を読んだことがありますが、仕様を決めるうえでの理由まで書かれており、本当に勉強になったという記憶が残っています。
    
  • JavaやC++の例外クラス（Javaならjava.lang.Exception。C++ならstd::exception。）
  
  
• Javaのインタフェースのようなものを設計する場合、C++の純粋仮想関数のみのクラスを設計する場合（要するに属性のないクラスを設計する場合）であってもデータ構成の洗い出しは必要です。
  これは、処理中心よりもデータ中心の方が保守しやすいこと、モジュールの強度（凝集度）の考えからそうなります。
  まあ、データが出てこない場合もありますが・・・。
  この時ですが、共通するデータだけではなく、そうでないデータ（個々の下位モジュールの実装に依存するデータ）にも注意を払ってください。考えておかないと、後で、「あ、このインタフェースだと必要なデータを渡せない・・・」的なことに陥ります。
  
  
• 設定値（各種パラメータ、使用アルゴリズムなど）を外部ファイル（設定ファイル）に記載しておき、システム起動時（あるいは、任意の機能の起動時）に読み込んで、使うということは良くあることです。
  この場合は、以下の点に注意してください。
  • 設定ファイルはコメントの記載ができるようにした方が良いです。設定値に関するコメントを記載したり、ちょっと変えてやってみるといったときに使います。
  • 設定値のチェックは厳格に行った方が良いです。
    具体的には、型のチェック（数値、小数、文字列）、範囲チェック、文字列長チェック、重複チェック（同じ項目を重複して定義していないか）、関連チェック（例えば、ある値が5だったら、別のある項目は10〜60でないといけないなど）です。
    それから、チェックエラーとなった場合には、どのファイルの（ファイルのパス）、何行目（場合によっては何列目という情報も）がなぜダメなのかを画面やログなどに出力してください。
    （ログの場合、一般に何もなければログは見てもらえませんから、「ログを見てください」的な情報をユーザに知らせる必要があります。）
    過去、チェックエラーになった場合や設定されていなかった場合に、「デフォルト値で動作させるのが良い」と言っている輩がいましたが、これはユーザが意図しない動作の原因になりうるので危険です。止めましょう。少しでもおかしかったらプログラムを動作させないで、確認させた方が良いです。
    
  • 設定ファイルを書く人が、設定値の修正・チェックを短時間で繰り返しできる作りが良いです。例えば、ファイル修正後、チェックするのに1時間かかるとしたら、大変です。
    
  • 設定ファイル（というかファイル）アクセスは一般に低速です。なので、１度全部取得し、メモリに展開し、２回目以降はそこから取得するようにした方が良いです。何度も何度もファイルを読みにいかないようにしましょう。
    それから、設定ファイルの読み出しにWindowsAPIのGetPrivateProfileStringを使う場合ですが、もし仮に設定項目が1000あった時にこの関数で取得すると、プログラムの動作が遅くなります。
    なぜなら1000回、ファイルにアクセスするから。
    なので、GetProfileStringで一気に取得し、取得した値をプログラム内で保持した方が処理が高速です。
    ※一般に、プログラム動作中にユーザが手で設定ファイルを直接いじるということはあまりありません。なので、プログラム起動時に全部読んで、メモリに格納すればいいです。で、ユーザが手で直接修正した時については、プログラムを再起動してくださいと制限事項にすればほとんどの場合事足ります。
    
  • 設定ファイルに「XXX=YYY」のみのような設定値ではなく処理を書きたい場合や、その他複雑な構文にしたい場合があります。この場合の設計についてはGoFのデザインパターンのインタプリタパターンが参考になると思います。
  
  
• 正常系のみ考えるのではなく、エラー処理（例外のスロー）にも注意を払ってください。
  これにより例外クラスの階層（継承関係）も設計する必要が出てきます。

3.参考文献

番号	著者名	書籍名	ISBN
1	結城 浩	増補改訂版Java言語で学ぶデザインパターン入門	978-4797327038
2	クレーグ・ラーマン著、依田　光江訳	実践UML 第3版 オブジェクト指向分析設計と反復型開発入門	978-4894716827