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

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

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

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


【Scrooge】クラス 設計 - 2

2008 年 05 月 05 日

前回、MainForm が ShopList と ItemList の2つを所有し、それぞれを配列に格納して入れ替えつつ使用するというところまで話を進めた。今回は、これら2つのクラスに求められる特性について検討してみよう。

2つのクラスに共通して求められる特性というのは、すなわち共通基底クラスである KeyList のことだ。このクラスの名前についてはもう少しなんとかならないかと思うが、ひとまず良い名前が思いつくまではこのままにする。これらが ShopDB や ItemDB の抽象化であることは明白なので、それぞれがそれぞれのデータベースのハンドルやオープン/クローズを行うといった話は割愛する。

さて、まずは画面右上のポップアップリストのデータとして使う場合だ。なによりもまず、要素の数が取得できなければならない。そして、各要素の名称が取得できなければならない。そして、ポップアップリストの選択状態が変更された場合にテーブルの更新を行うため、それぞれのレコードの UniqueID が取得できなければならない。ひとまずポップアップリストについてはこれくらいだろう。

...と、「これくらい」で済ませてしまってはならない。なぜなら、以下のようなイメージを持ってしまうとマズいからだ。

class KeyList {
public:
    virtual UInt16 GetSize( ) const = 0;
    virtual UInt32 GetRecordID( UInt16 idx ) const = 0;
    virtual const char* GetRecordName( UInt16 idx ) const = 0;
};

最後のメンバ関数は、レコードをロックしてから文字列ポインタを取得する(逆に言えば文字列ポインタが不要になり次第レコードロックを解除する)必要があるはずなのに、復帰値として得られた NULL 終端文字列の有効期限は定かでない。一般に、リソースのロックなどといった制約がある環境では、上記のようなアクセサメソッドは使用できないのだ。使用できるのは、データ回収用のバッファを渡してコピーを貰う方法か、あるいはデータの有効期限を当のクラス自身が完全に制御できるようにする方法しかない。

この手の話は、結局効率と汎用性のせめぎ合いになる。Scrooge では、できるだけヒープの使用や冗長なデータ構造を避けようという(個人的な)方針があるため、ひとまずリストの内容を描画するためのメソッドそのものを KeyList に持たせてみることにしよう。コールバック関数を使用してリストの内容を描画する方式の中で、必要なパラメータを渡して KeyList 自身に描画を行なわせることにする。

続きは明日。

 

コメント

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

 

このページのタグ

Page tag : Palm

 

 


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