2008-05-04-01-【Scrooge】クラス 設計 - 1 - project-enigma

2008-05-04-01-【Scrooge】クラス 設計 - 1

>> Site top >> weblog >> 月別アーカイブ >> 2008年05月のlog >> 2008-05-04-01-【Scrooge】クラス 設計 - 1

最終更新日付:2014/01/02 00:00:00


【Scrooge】クラス 設計 - 1

2008 年 05 月 04 日

昨日、実際にコードを起こし始めてみて、全然うまくいかないことに気付いた。まぁそれも無理はない。データベースに格納するデータの構造はイメージできていても、それがそのままコードに対応するとは限らないからだ。もっと言うのであれば、使う言語との細部のすりあわせをしていないからだ。通常、「書きながら考える」いつものやり方では、細部の噛み合わない部分を埋める作業は少しずつ進行するため、ほとんど気にならない。しかし、今回のようなやり方では、細部を詰める作業がまったくないまま大きな構造が先に決まってしまった。結果として細部の噛み合わなさが(陰郎の中では)非常に目立つような気がして疎ましい。

愚痴を書いていても始まらないので、大雑把なところからコード片をばら撒いてみよう。まず前提として Scrooge ではモードレスフォームは1つだけで、他のモーダルフォームは全てこのメインフォームから表示されると仮定してよい。なので、商品一覧や店舗一覧を抽象化するクラスはこのモードレスフォームのクラスが所有してしまって良いだろう。

そして、画面上のインタラクションについてこれまで見てきたとおり、商品一覧と店舗一覧は互いに交換可能なものとして扱えることが望ましい。現時点では短絡的に、KeyList というクラスを共通基底クラスとして持たせる。

先の図では MainForm から2つのクラスに引かれた線はコンポジションだった。しかし、これはあくまで MainForm がこれらのクラスを所有し、生殺与奪を握ることしか意味していない。メインフォームでは、常にどちらか一方がポップアップトリガーの一覧に表示され、他方はテーブルに一覧表示される。この切り換えを簡単にするために、2つのオブジェクトを使用するためのポインタ配列を用意する。

class MainForm {
//       :
//       :
private:
    KeyList* m_pLists[2];
};

m_pLists 配列の要素は m_shopList と m_itemList のアドレスが入る。常に最初の要素がポップアップトリガー用であり、最後の要素がテーブル用である。つまり、ビューが切り換えられる度にこの配列のメンバは交換される。アプリケーション起動時の状態復元を度外視すれば、コンストラクタ/デストラクタで以下のようなアロケートと開放を行なうことになる。

MainForm::MainForm( ) {
    m_pLists[0] = new ShopList( );
    m_pLists[1] = new ItemList( );
}

MainForm::~MainForm( ) {
    delete m_pLists[0];
    delete m_pLists[1];
}

では、実際のところ ShopList と ItemList というクラスは一体どんなものだろうか。メインフォームは、これらのクラスに何を期待するだろうか。それについては明日。

 

コメント

このページにコメントする

 

このページのタグ

Page tag : Palm

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.