(まさかここを見ていると思ってなかった)友人から突っ込みがありまして、一部、補足・訂正致します。
○グローバルに関して
・Globalsと言うモジュール名が重要なのでは無くて、個々のプロパティなどのスコープが
Globalと指定されている必要があります。
ここでPrivateを指定すると、Globalsモジュールのプライベートとなってしまいます。
・グローバルの使用は最低必要限に留めるべきす。
○Original Class
・ArrayWarpperにあるmArray As Variantですが、Vatiantに関するドキュメントを参照して頂ければ
解ると思いますが、任意のオブジェクトを代入する事ができますので、基本的にList, Queue, Stackは
そのまま使って問題が無いと考えています。
これは、Variant型がどの型のオブジェクトを保持しているかを記録しているので、代入/参照時に
暗黙的に型変換を行っています。
ただ注意点として、今回のサンプルのようにオブジェクト型の配列を保持していると、直接の型変換が
出来ず、コンパイル時にエラーとなってしまいます。
このため、一旦、Variant型で参照して、その Variant型を使って、For Each等で繰り返しを処理する事で
回避しています。
○UserIFControlThread
・新規プロジェクトに利用する際に、Run イベントハンドラは基本的に変更する必要はありません。
・UserInterfaceUpdate()ハンドラを適宜、修正してください。
・多くのコントロールを扱う際には、関連するコントロールをコンテナにまとめて、そのコンテナの
メソッドで内包するコントロールだけの処理を行うべきです。
このコンテナのメソッドをUserInterfaceUpdate()から呼び出すと良いでしょう。
○DigitalClockContainer
・あえて説明しなかったのですが、このコンテナは前回のデジタルクロックアプリケーションを元に、
中心となるデジタルクロック表示をまとめて、コンテナにした物です。
このコンテナをウィンドウにレイアウトするだけで、デジタルクロック表示ができて、毎秒ごとの
画面更新も実行してくれる優れものです。
この様にクラスの独立性を高めて行く事で、デバッグ、テスト等の工数が減少し、再利用性が向上します。
OOPと言えども、作成する側がこの事を意識しないと、スパゲッティプログラムになってしまい。
後々の工程に影響します。
・他のクラス(オブジェクト)のメソッドやプロパティを参照・利用を極力しない。
→その様な場合はクラス設計が間違っている、あるいは、検討不足である事が多いので
一度立ち止まって考え直す。
・そもそも、1本のアプリケーションとして実装する必要があるのかも含めて、原点に返る事も
作業を単純化するためには必要である。
前回のデジタルクロックと今回のアラームアプリケーションは、独立したアプリケーションである事が
意味を持っています。
クロック表示するのは別の画面で分かりやすくしておいて、アラームは画面を表示しておく必要は
必ずしも無いのです。