何となく Blog by Jitta
Microsoft .NET 考

目次

Blog 利用状況
  • 投稿数 - 761
  • 記事 - 18
  • コメント - 36194
  • トラックバック - 222
ニュース
  • IE7以前では、表示がおかしい。div の解釈に問題があるようだ。
    IE8の場合は、「互換」表示を OFF にしてください。
  • 検索エンジンで来られた方へ:
    お望みの情報は見つかりましたか? よろしければ、コメント欄にどのような情報を探していたのか、ご記入ください。
It's ME!
  • はなおか じった
  • 世界遺産の近くに住んでます。
  • Microsoft MVP for Visual Developer ASP/ASP.NET 10, 2004 - 9, 2011
広告

記事カテゴリ

書庫

日記カテゴリ

ギャラリ

その他

わんくま同盟

同郷

 

部分型定義(その2)(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
コメント
  • # re: 私が考える、部分定義のメリット
    渋木宏明(ひどり)
    Posted @ 2007/04/08 15:21
    C#3.0 で導入予定の extention method でもほぼ同様のことが出来ますが、これはこれで「拡張メソッドをどのクラスのメンバにするか」って問題があって悩ましいところです。
  • # re: 私が考える、部分定義のメリット
    シャノン
    Posted @ 2007/04/08 15:26
    正直なところ、どこまで行っても「デザイナのための機能」なんですよね。
    とは言え、もはやデザイナやIDEを使わない開発など考えられなくなって来ているので、デザイナとの連携をいかに便利に使うかは重要な視点ではあるのですが…
    やっぱり、デザイナやIDEありきのライブラリや言語仕様は今一つ好きになれなかったりします。
  • # re: 私が考える、部分定義のメリット
    まどか
    Posted @ 2007/04/09 0:11
    > 正直なところ、どこまで行っても「デザイナのための機能」なんですよね。

    さすがにそこまでは思ったことありませんが
    やはりDesigner.vbのように目的が「隠蔽」であること以外に
    使い道を思いついたことはありませんねぇ。
  • # re: 私が考える、部分定義のメリット
    R・田中一郎
    Posted @ 2007/04/09 13:13
    >ここに有効に働くのが、パーシャル クラスです。

    なるほど深く納得です。
    実は、つい先ほども、こういう使い方をしたばかりでした。
  • # re: 私が考える、部分定義のメリット
    Jitta
    Posted @ 2007/04/09 21:23

    ひどりさん、シャノンさん、まどかさん、R・田中一郎さん、コメントありがとうございます。

    > 正直なところ、どこまで行っても「デザイナのための機能」なんですよね。
     たとえば、仕様書からコードを生成するツールを作ることもできます。これは、「デザイナ」とは、ちょっと違いますよね。このとき、「仕様書から生成されるコード」と、「一律に追加したいコード」を別々に生成することもできます。
     「デザイナ」とは限らないと思うので、「コード ビルダ」としました。


    > 実は、つい先ほども、こういう使い方をしたばかりでした。
    世の中そんなもんよねぇ~♪
  • # re: 私が考える、部分定義のメリット
    シャノン
    Posted @ 2007/04/10 18:28
    > 「デザイナ」とは限らないと思うので、「コード ビルダ」としました。

    うん。
    「デザイナ」は限定しすぎだったかもしれないけど、もっと拡大解釈しても「ツールのための言語仕様」の域を出ないと思うのね。
    で、それは「ツールを使わなければ邪魔な言語仕様」なんです。個人的には。
    現実的には、ツールを一切使わない開発ってあり得ないと思うからいいけれど、個人的な理想を言えば、言語仕様はツールに影響されず、それでいて、ツールともうまく連携できるものであってほしかったかな、と。
    あるいは、ツールとの連携に有利な仕様であったとしても、それはツールとの連携を主目的にした機能ではなくて、「ツールを使わなくても十分に有用な機能だけど、ツールとの連携にも便利」な機能であってほしかった。
    #あくまで理想論ですよ。
  • # re: 私が考える、部分定義のメリット
    Jitta
    Posted @ 2007/04/11 23:39
    > 言語仕様はツールに影響されず、それでいて、ツールともうまく連携できるものであってほしかったかな、と。
    難しいこと言いますね(^-^;
  • # re: 私が考える、部分定義のメリット
    Jitta
    Posted @ 2007/04/18 22:08
    「partial クラス メリット」での検索急上昇中。

    あなたが思ったメリットを、他の人のために書き残してくださいませんか?
タイトル
名前
Url
コメント