部分型定義（その２）（R.Tanaka.Ichiro's Blog）より：
ところで、
デザイナ
を使ってフォームを作るとファイルが二つに分かることはご存じでしょうか？
実は、これもパーシャルクラスによるものです。
以下は、C# で Form1 というフォームクラスを追加した時に、自動的に作成されたファイルのサンプルです。
ファイル名：Form1.cs
public partial class Form1 : Form
{...
ファイル名：Form1.Designer.cs
partial class Form1
{...
さて、話を元に戻します。
私としては、フォームだけで終わって欲しくなかったので、私が考えるメリットを書きます。
Visual Studio.NET、および 2003 にも、DataSet デザイナがあります。こいつでデザインすると、XML Schema と、DataSet, DataTable, DataColumn, DataRow クラスを生成してくれます。便利ですね。でも、ちょっと待ってください。このクラス、かゆいところに手が届かないのです。
たとえば、「このテーブルに定義されている列名の一覧が文字列配列で欲しい」と思ったとします。すると、外部から DataTable を取り出し、そこから DataColumn クラスを引き出して、列挙してやらなければならない。ちょっと待ってください。オブジェクト指向は「自分のことは自分でする」が基本じゃないですか？DataTable の中に定義されている列名の一覧を、DataTable 自身が提供せずにどうします？
もちろん、生成されたコードを修正すれば、そういうことも可能です。しかし。そうしてしまうと、今度はデザイナで修正するごとに、コードを修正し直さなければならない。
ああ、面倒くさい！！
ここに有効に働くのが、パーシャル クラスです。
フォームの修正をしても、そんなのは所詮、Initialize メソッドと宣言あたりですんでしまいます。つまり、7.x バージョンでは region で囲まれていた範囲ですね。しかし、DataSet デザイナや CrystalReports は、ファイルを書き直してしまいます。こういうものに対しても、独自の宣言を追加できてしまうのです！！
もちろん、ここで止まりません。独自のコード ビルダーを作ったとしても、そのコード ビルダーの使用者は、あなたが生成部分をどのように実装していようが、あなたにお構いなしに独自の宣言を追加できるのです。
ね？便利でしょ？
επιστημηさんが危惧されているように、やり過ぎると「いったいこのクラスは、いつ完成するの？！」ということになります。私は、「自動生成コード」と、「そこに手動追加するコード」くらいの切り分けにしておく方がいいんじゃないかと思います。
投稿日時 : 2007年4月7日 21:03