第１８章　再利用基盤モデル

• コンポーネント、フレームワークなどのような再利用部品の利用者から見える論理単位
• クラスライブラリ全体における一貫した例外処理やエラー処理
• 構築されている再利用部品の中で一貫性のあるメソッド体型や呼び出すためのルール

図18-1 高次元分析におけるレイア構造

１．役割レイアに分類する意義

２．再利用レイアに分類する意義

３．役割・再利用レイアに分類することによる効果のまとめ

• 役割レイア・再利用レイアに問題を分割してクラスを抽出することで、クラス間の独立性を高め、依存性を低くするような設計指針を立てやすい。
• 役割レイアの分類により、変更・拡張に耐えやすい適度なバランスを保ったモデル構造を作りやすい。
• 役割レイアの分類により、ネットワーク３層アーキテクチャなど、ネットワーク対応ソフトウェアの設計に適合しやすい。
• 再利用レイアに問題を分割してクラスを抽出することで、再利用コンポーネントを抽出する可能性が高まる。
• 再利用レイアの分類を明確にすることにより、再利用範囲の大枠をコンポーネントユーザに伝えることができる。
• 再利用レイアの分類を明確にすることにより、無駄な部分に対する再利用のためのコストをかけなくなる。

• 問題領域主導型プロセス
  　このパターンは、ADGのシステム共通設計フェーズにて、問題領域の中からコンポーネントを抽出しようとする際に実践される。先に問題領域があり、その中から徐々に再利用コンポーネントを抽出していく方法。この方法は、企業内で再利用可能なフレームワークやコンポーネントを抽出するのに適している。
  
  
• コンセプト主導型プロセス
  　このパターンは、コンポーネントやフレームワークとしてのアイデアがすでにあり、あとはソフトウェアデザインするだけといった、コンポーネント化のアイデアが先行している際に使われる。この場合、どのシステムでコンポーネントが使われるかといった問題は後回しにされ、ODGによるコンポーネント分析にすぐさま開始されることになる。

図18-9 再利用基盤モデル実施プロセス

• Ｑ１　役割による分離はオブジェクト指向的ではない
  　そもそもView、Process、DataManageなどといった分類は、自分のことはオブジェクト自身でやるといった純粋なオブジェクト指向にはそぐわないもののような気がするが？
  
  
• Ａ１　ＮＯ
  　古典的なオブジェクト指向方法論には、このような役割分担は存在しなかった。そのころオブジェクト指向分析・設計を学んだ人たちは、おそらく役割分担について初めは馴染めないかもしれない。しかし、Smalltalkによって確立されたオブジェクト指向プログラミングには、Model、View、Controller といった分類がフレームワークとしてなされていたのである。これらは、DataManage、View、Processに類似している。(この違いは後ほど示す)
  　よって、なにが純粋であるかは別として、このように３つの役割別にオブジェクトを分類させることは、オブジェクト指向の基本ともいえる。
  
  
  
• Ｑ２ 　Ａ１に対する質問。
  もともと３つの役割に分類することがオブジェクト指向の基本ならば、それは拡張性に問題があるといえるのではないか？なぜなら、１つの問題に対する役割が３つのクラスに分類されてしまうと、問題に変更が加わった時に、１つで良かった変更箇所が３つに増えてしまうではないか？
  
  
• Ａ２　設計バランスを保つための最適解である。
  　役割分担は、オブジェクト指向がオブジェクトを分類することから開始されるのに対して、オブジェクトを初めからView、Process、DataManageという３つの役割に分類するということから開始する。その結果、オブジェクトの属性(これはDataMangeに属するオブジェクトの属性ということ)に何らかの変更が加えられた場合は、その変更箇所がViewやProcessに影響を及ぼすことになるという問題は確かにある。
  　しかしながら、もしView、Process、DataManageに分類せずにオブジェクトを抽出すると、本章でかかれたクラスレイアカテゴリによるレイア分割の効果が得られない。結局、この問題は、両問題の重要性と問題を起こす頻度の度合いによりトレードオフした結果、View、Process、DataManageに役割分類した方がよいという結論となるのである。また、この問題は、以下のような対策により問題を部分的に回避することができる。
  
  
  • DataManageに属するオブジェクトを本質的なオブジェクトと見なし、問題領域分析当初から集中的にDataManageを分析する。その結果分析漏れが少なくなり、分析漏れによる変更も少なくなる。
    
    
  • フレームワークのアーキテクチャによって、View、Process、DataManageの関連をフレームワークの提供する抽象クラスでカプセル化しておき、DataManageに属するクラスに一定のプロトコル(インタフェース)を設ける。たとえば、DataManageに属するオブジェクトを印刷するという時は、印刷オブジェクト(Graphics)がDataManageのprintOnメッセージのパラメータとして渡されるようにフレームワークの構造として設計しておく。このイメージを図18-10に示す。図では、AppPartsにフレームワークを構築した例である。
    　このようなフレームワークによって、出力デバイスを抽象化したGraphicsオブジェクトを使いDataManageに属するオブジェクトが自分自身を出力するロジックを記述することができるようになる。そのためデータに変更があっても、DataManageに属するデータ管理クラスだけを変更すればよくなる。また、出力デバイスを抽象化するProcess(図中ProcessPartsクラス)のおかげで、DataManageに属するオブジェクトは、印刷デバイスに関する細かな制御について意識しなくてよくなり、印刷制御はPrinterクラス(Process)に任せるという役割分類の恩恵はそのまま残しておける。しかし、DataManageはProcessに属するオブジェクトに部分的に依存してしまうことについて妥協しなければならない。
    　このようなフレームワークアーキテクチャで問題を回避できる範囲は、あくまでフレームワーク設計者が想定している範囲となり、これについても完全な対策ではない。
  
  
  
  
  

  図18-10 フレームワークアーキテクチャによって印刷オブジェクトをDataManageに渡す

  
  
  
  
  
• Ｑ３　CollectionなどはDataManageに属するのでは？
  　図18-2に書かれているCollectionカテゴリは、データを管理するためのコレクション(入れ物)であり、それはDataManageに属すべきものではないか？
  
  
• Ａ３　ＮＯ
  　コレクションは、データを管理するオブジェクト(DataManage)を管理するための制御(Process)と考えなければならない。これに類似する問題としてデータベースアクセスクラスやそれに付随するコレクションなどもProcessに属するものである。DataManageに属するクラスは、オブジェクト指向データベースに格納されるクラスやRDBの表に相当するクラスなど、データ構造をラップして抽象操作するためにオブジェクト化したものと考えればよい。
  
  
  
• Ｑ４ 　Ａ３に対する質問。
  　もしオブジェクト指向データベースを使うのならデータ管理オブジェクトだけを永続化するような考えは必要ではない。なぜなら、制御やウインドウ処理を対象とするオブジェクトも永続化の対象となるわけで、それらを区別する必要などないのではないか？
  
  
• Ａ４　区別すべきである
  　オブジェクト指向データベースを使っていてもView、Process、DataManageという分類は有効なものである。なぜなら、DataManageの属するオブジェクトはできるだけ汎用的なデータ操作に対応するような構造でなければならない。もしも、永続オブジェクトに機能が多く組み込まれているならば、その保守性は極めて悪いものとなる。
  　これは、プログラムからデータを独立させるというデータベースの基本思想に由来する考えであるが、オブジェクト指向の思想であるデータと処理をまとめてオブジェクトにするという考えに反しているようにも思える。この点にデータストアを必要とするオブジェクト指向ソフトウェアの現実的な妥協点を探る必要がでてくる。データ独立を図れるように、データ管理に対する汎用的な操作だけを持つクラスをDataManageに属するオブジェクトとして作り、それを永続オブジェクトとしてオブジェクト指向データベースによって管理させることで、データ独立という思想とオブジェクト指向の思想をバランスよく組み合わせた折衷案とすることができる。これがオブジェクト指向データベースにおいてもDataManageの存在が必要とされる理由である。
  
  
  
• Ｑ５　状態管理オブジェクトはDataManageか？
  　システムのいくつかの状態を管理するために状態管理クラスを作成した。クラスの中には、状態をデータとして保有している。このようなクラスはDataManageに属するのか？
  
  
• Ａ５　ＮＯ
  　DataManageに属するオブジェクトはあくまで永続化する必要のあるデータを管理するものである。もし、状態をプログラム終了後も保管しておく必要があるならDataManageに属するよう設計することになる。
  
  
  
  
• Ｑ６　DataManageに該当するオブジェクトがない
  　我々の開発するツールにはDataManageに該当するオブジェクトがない。これは重要なオブジェクトを見つけていないということなのか？
  
  
• Ａ６　なくてもよい
  　特に問題はない。データ処理よりも制御が中心となるようなソフトウェアでは、DataManageに属するオブジェクトがないこともあり得る。その場合、要求からProcessを見つけるようにしよう。