【DO!BOOK・ページリンク】
2008_migaro_techreport_001   96 / 136

BOOKをみる

10秒後にBOOKのページに移動します


94 での活用範囲をさらに広げることができ る。 2-4. イベント制御  継承元フォームに配置するコンポーネ ント同様、どのイベントをどこまで継承 元で制御するかも重要なポイントであ る。  例えば、[閉じる]ボタンを押下した ときにフォームを閉じるといったイベン トは、継承元フォームで記述するという ことは想像しやすいだろう。また、検索 や更新などの画面固有の処理は、継承先 フォームに処理を記述すればよい。これ らの切り分けは比較的簡単に行える。  では、画面起動時の処理を行うイベン トは、継承元フォームと継承先フォーム のどちらで処理を記述するべきだろう か。画面起動時に行う処理を考えてみよ う。 【画面起動時の処理】 @画面項目をクリアする。 A画面項目に初期値をセットする。  @は、画面全体に対しての処理なので、 前述の2-3 のように継承元フォームで処 理できそうである。一方、Aの初期値は、 画面ごとに内容やセットする項目が異な るため、継承先フォームで処理すること になるだろう。  なお、こういった場合、イベントの処 理内容はどちらかにまとめて記述する必 要がある、というようなことはない。 @ のイベント処理は、継承元フォームに 記述しておくことができる。 A の内容は、継承先フォームで同イベン トに記述する。  ここで気をつけなければならないの は、同じイベントが、それぞれどのタイ ミングで実行されるかということであ る。【ソース3】【ソース4】  同じイベントで処理を記述した場合、 継承元フォームのイベント内容は inherited の箇所で実行される。  これは、デバッグ実行時におけるF7 キーでのトレースやShowMessage を 組み込んで、実行される実際の順番を確 認すると理解しやすい。  つまり、こういったイベント内の内容 を切り分けることによっても、継承先 フォームでの開発負担を軽減することが できる。 2-5 アクションコンポーネントの利用  別の視点からイベントを見てみよう か。前述の@とAの処理順は決まってい るので、この処理順を、継承元フォーム で制御することはできないだろうか。  そのような場合に便利に使えるのが、 TActionList というコンポーネントであ る。TActionList では、TAction とい うアクションコンポーネントを持つこと ができる。このTAction コンポーネン トであらかじめ想定される動作を用意し ておけば、継承元フォームで、継承先の イベントの制御に利用することができ る。【図6】  例えば、Aの初期値設定処理を想定し て、アクションとしてacDefault という TAction コンポーネントを継承元 フォームに配置しておく。  このアクションを利用して、前述の画 面起動時の処理を変えてみよう。【ソー ス5】【ソース6】  一見、同じようなプログラムに見える が、処理@Aの順番を制御しているのは、 継承元フォームである。  これにより、フォーム継承を利用して 個別画面(継承先フォーム)を作成する 開発者は、inherited などの継承を考慮 する必要がなくなる。acDefaultExecute イベントに初期値設定の処理を記述して おけば、継承元フォームが自動的に適切 な箇所でその処理を呼び出してくれる。  例えば、acDefault は初期値設定処理、 acSearch は検索処理など、アクション 名を決定して継承元フォームに配置して おく。そうすれば、各開発者はそのアク ションのロジック作成のみに専念するこ とができ、また、システム全体としても 動作の統一を行うことが容易になる。 3 アプリケーション内の 継承構成  2 で、継承元フォームの作成のポイン トをまとめた。では、この継承元フォー ムは一体どの程度用意しておけばよいの だろうか。  フォームの継承は何階層でも多重継承 が可能なので、汎用性を考えると細分化 された継承フォームを用意する必要があ る。  例えば、メニュー画面、検索画面、更 新画面から構成されるアプリケーション の構成を考えてみよう。  まず単純に、3 つの画面フォームのパ ターンが考えられる。【図7】  このうち、アプリケーション共通の画 面デザイン(タイトルラベルやセッショ ン表示など)を別々に作成する必要はな いので、画面デザインだけの共通フォー ムを用意する。【図8】  また、同じように検索処理画面におい ても、一覧検索画面や詳細情報検索画面 などレイアウトが異なる可能性があるの で、検索ボタンを配置した検索の共通画 面を用意する。同様に、更新画面も画面 のパターンを用意する。【図9】  このように、継承フォームを細分化す れば、より多くの画面に対応することが できる。その際、構築するシステムの規 模や複雑さ、画面パターンなどによって、 その細分化のレベルは異なる。  また、新しいパターンの画面が追加さ れた場合は、それに対応する継承フォー ムを追加していけばよい。そのため、後 から継承フォームが追加できるように細 分化を考えておく必要がある。  ただし、継承フォームの細分化によっ て汎用的で便利になる一方、継承フォー ム自体の管理が手間になってしまっては 意味がない。その見極めには十分に配慮 する必要がある。 4 フォーム継承による メリット  フォーム継承を利用するときには、さ まざまな開発ポイントがある。  システム構築当初に、これらをしっか り検討してフォームの継承を利用すれ ば、システム構築では、以下のような利 点が得られる。 ●開発効率 @ 1 画面あたりの開発工数が少なくな る。   同系統の画面作成に、同じ工数をかけ る必要がなくなる。 A 開発者に求められるプログラムの敷居 を下げることができる。   難易度の高い共通ロジックを継承元で