向こうにポストしようかと思ったけど、ずいぶん本文から外れるので、ブログにしてみる。
複数フォームで同じコードを書いてあるのですが。（Insider.NET 会議室）より：
NAL-6295さんの書き込み (2007-06-08 23:45) より:
そういうデータで初期化する、ComboBox を継承したコントロールを作る。
public class MyComboBox : ComboBox
{
public MyComboBox() : base() {
this.Items.Add("指定しない");
this.Items.Add("内容１");
this.Items.Add("内容２");
this.DropDownStyle = ComboBoxStyle.DropDownList;
this.SelectedIndex = 0;
}
}
これをやっちゃうとデータの種類分だけ作成する必要があって、現実的な解では無いのでは？
そうなんです。今の課題。「データの種類分だけ作るのか？」
以前のプロジェクトでは、データの種類分だけ作ってみました。
基本的に、フレームワークに用意されているコントロールは、かなり汎化されています。そのため、何らかの動作をさせようとすると、コントロールを配置したコンテナ コントロール(たいていの場合は Form)に、コントロールが行う動作をコーディングすることになります。
ここです。コントロールが行う動作をコーディングする。
「顧客マスタ」と「商品マスタ」で、選択された後に行うことは違います。その違いをコンテナ（つまり Form）に書いていくと、結局複数フォームで同じコードを書いてあるのですが、アプリを作成中にこれでいいのかなと悩んでます。
という状態になるのではないでしょうか。
しかし、データごとにコントロールを作ると、本当に「ポトリ、ペタリ」で拡張できるようになります。
その代わり、それぞれのコントロールが何をしなければならないのか、しっかり分析／設計しなければなりません。
なぜそうしてみたかというと、仕様変更による修正を局所化できるのです。
最初は、仕様書には「選択できること。」としか書かれていないわけですよ。で、自分で書き込むことができないので DropDownList で実装します。すると、一旦選択した後、「選択していない状態」に戻せないのです。そんなわけで、仕様書が書き換わるのです。「選択できること。また、選択していない状態に戻せること。」というように。
標準の ComboBox をそのまま使っているなら、データが使われているところをすべて探し出して、処理を書き換えなければなりません。
標準の CommoBox を継承したコントロールを使っているなら、拡張コントロールに「未選択状態があり得る」というフラグでも追加して、コントロールが初期化されているところをすべて探し出して、プロパティを変更する必要があります。
データごとに ComboBox を継承したコントロールを使っているなら、このコントロールが初期化されているところのみ探し出して、プロパティを設定するコードを追加すればいいことになります。
私は、VC++ が目指している「部品化」というのは、こういうことなのかなぁ？と思っています。
もちろん、このようにして作った部品は、そのプロジェクトの中だけでしか有効でないものが多くなります。また、コントロールのデータに対する依存性が強すぎると（たとえば、「このデータベースのこのテーブルから持ってくる」とコーディングされていたりすると）、データの変更に弱くなります。この辺は汎化した方が良く、汎化と特化のバランスが微妙ですけど。
だから、先にきちんと設計しなければならないわけで、現在の課題なんです。
投稿日時 : 2007年6月11日 21:54