久しぶりにVB6をさわったら、既定のインスタンスが大好きになってしまいそうです。どうしよう。これが恋？
コメントにしたら長くなりそうなので円取り立てましたエントリ立てました。
いわゆる業務アプリ開発において。
画面がいくつかあるとします。
画面遷移図が木構造になっておらず、AからB、BからC、CからAという遷移が可能だとします（BとCを通ってAに戻るイメージです）。
木構造ならモーダルフォームで楽が出来るのですが、このように輪になっているとそれはできません。
こういう場合、次に表示する画面を毎回 new するわけにはいかないので、一度作った画面のインスタンスは、遷移元画面クラスの外に置かなければなりません。
既定のインスタンスは、それを暗黙のうちにやってくれるものと言うことができます。
VB6.0 で「Form の既定のインスタンス」を防ぐには?
防ぐなｗ
このような、正当な方法を利用するメリットはいくつかあります。
- インスタンスを生成することで、初期化が保証される
- スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
- 結果、他の場所から勝手に呼び出されてしまう心配がない
- 外部のどこから操作されているのか明確になる
- 別のインスタンスを作って複製可能
ふむふむ？
- インスタンスを生成することで、初期化が保証される
- 既定のインスタンスを使うと初期化されないんですの？
既定のインスタンスのメソッドを最初に呼んだ時に Initialize が走るって書いてありますやん。
- スコープを狭めることができる (例のコードでは Command1_Click プロシージャ内でのみ有効)
- それじゃ狭すぎて困るんです。遷移元画面よりも広いスコープが必要なんです。
- 結果、他の場所から勝手に呼び出されてしまう心配がない
- 外部のどこから操作されているのか明確になる
- どこかで一元管理しているなら別として、遷移元画面で new しているような状況では、そんなに変わらないと思いますが。
- 別のインスタンスを作って複製可能
- 実のところ、同じ画面のインスタンスをいくつも作る必要がある場合というのは、そう多くないものです。
画面管理クラスをちゃんと設計して、遷移元画面から直接次の画面を Show しないように作るのが正道かもしれませんが、理想と現実は得てして異なるものです。
# 100以上のフォームを、「動かなくてもいいから、とりあえず今日中に画面遷移だけでもするようにしてくれ」って昼過ぎに言われてもね…。