Visual Basic 2005 ここが便利！ 第3回 自動生成コードを分離、ソースをすっきりパーシャル・クラス 株式会社ピーデー　川俣 晶 2005/04/13

Visual Studio 2005や.NET Framework 2.0の登場とともに、プログラミング言語であるVisual Basic .NETも「Visual Basic 2005」へとバージョン・アップする。この新しいVisual Basicには、言語仕様の面でも統合開発環境の面でも、プログラミングを楽にする新機能が満載だ。本連載ではその中でも特に注目すべき便利な機能を1つずつピックアップしながら紹介していく。

いじってはいけない危険なコード

Back Issue

1 “My”はクラスの海からVBプログラマを救う！？ 2 型指定されたコレクションを実現するジェネリック

　Visual Basic 6.0（以下、VB 6）からVisual Basic .NET（以下、VB.NET）への変化は、おおむね機能強化や改善として受け止めることができる。しかし、中には改善ではなく、改悪としかいいようのない変更も含まれている。

　その1つが、自動生成されたコード中に出現する「書き換えられるのに書き換えてはならないコード」である。

　例えば、Visual Studio .NET 2003（以下、VS.NET 2003）で、VB.NETのWindowsアプリケーションのプロジェクトを生成すると、そこには以下のようなコードが含まれている。初期状態では表示されないが、「Windows フォーム デザイナで生成されたコード」という行の左側の＋記号をクリックするだけの、いとも簡単な操作で見られるようになり、書き換えも可能になる。

VS.NET 2003が自動生成するWindowsフォームのためのコード

これらのコードは初期状態では隠されているが、「Windows フォーム デザイナで生成されたコード」の部分を展開することにより表示され、変更することもできる。ただしその変更により、デザイナでフォームが開けなくなったり、Windowsフォームのデザイナにより上書きされたりする可能性がある。

　このコードは、コメントに書かれたとおり、VS.NET 2003のフォーム・デザイナでフォームをデザインした結果によって自動的に書き換えられるものであり、手動で書き換えてはならない。書き換えるとどのような不整合、どのようなトラブルが起きるか分からない。そのような性質を持った危険なコードである。

　しかし、いくら注意しても、不注意によりコードを書き換えてしまうことがあるだろう。うっかりキーボードに触れたことに気付かないというケースや、一括置換などで気付かないうちに書き換えてしまうケースもあり得る。

　危険であるにもかかわらず、たかがクリック1回で表示され、ほかのコードを編集するのと同じように書き換えてしまうことができる。このような事態は、VB 6ではあまり見られなかったことであり、明らかにVB.NETになって改悪された部分だといえる。

理由はいろいろある……

　もちろん、技術的な観点から、どうしてこのような改悪とも思える構造に変更しなければならなかったのか、その理由はよく分かる。あるフォームに含まれる機能を、1つのクラス定義という形にまとめるとすれば、それは1つのソース・ファイルにすべてを納める必要がある。自動生成されるコードも、プログラマが自ら書き込むコードも、1つのソース・ファイルの中にすべてを納める必要があるのだ。それは、VB.NETのクラスという機能が持つ制約に起因する避けられない仕様である。

　念のために補足すると、VB 6でこのような問題が起きていないのは、VB 6のフォームが、クラスとは異なる独立した機能であるためだ。フォームはクラスではないので、クラスの制約を受けることはない。ちなみに、歴史的にいえば、フォームはVisual Basicの最初のバージョンからサポートされているが、クラスは途中から追加された機能にすぎない。

　しかし、フォームはクラスの一種として定義しても何ら問題ないものであり、クラスとフォームという異なる機能を持つことはシステムに不必要な複雑さをもたらしてしまう。それ故に、フォームがクラスに吸収統合されたことは自然な流れといえる。つまり、独立したフォームという機能が消え、クラスによって実現されたフォームに取って代わられるのは大きな流れの中で要請される必然なのである。書き換えてはならないコードが見えてしまう問題は、フォームへの先祖返りではなく、新しい対策が必要とされるのである。

クラスの制約を乗り越えるパーシャル・クラス

　Visual Basic 2005では、この問題への根本的な対策が採られている。

　Visual Basic 2005 Express Editionのベータ版で、同じようにWindowsアプリケーションのプロジェクトを作成し、コードを表示させてみた。すると、驚くなかれ、コード・エディタで表示されたのは以下の内容だけだ。

Public Class Form1 End Class

Visual Basic 2005が自動生成するWindowsフォームのためのコード

　なんと空行を含め、たった3行しかない。フォーム・デザイナが自動生成するコードなど、どこにも見えない。どこかをクリックすると表示されるといったこともない。本当に3行だけしかないのである。これで、書き換えてはならないコードを誤って書き換えてしまうという問題にはサヨナラである。

　しかし、これはおかしいと思う読者もいるだろう。そう、クラスという機能の制約上、クラスが持つべき機能はすべて1つのクラス定義に含まれている必要がある。しかし、このクラスの定義は空であり、本来必要とされる定義が欠けている。

　その疑問への答が、「パーシャル・クラス」（Partial Class：Partialは「部分的な」という意味）というVisual Basic 2005の新しい機能である。これは、1つのクラス定義を複数のクラス定義に分散させることを可能にする機能だ。

　実際にそれを確認するのは簡単である。プロジェクトを保存した後で、実際に作成されたファイルを調べると、Form1クラスを定義する上記のコードは「Form1.vb」というファイルに格納されることが分かる。しかし、それと並んで、統合開発環境上では表示されなかった「Form1.Designer.vb」というファイルも見つかるだろう。このファイルにも、Form1クラスを定義するコードが含まれている。

　このForm1.Designer.vbを開くと、以下のようなVS.NET 2003で見慣れたコードがぞろぞろと出てくる。

Partial Public Class Form1   Inherits System.Windows.Forms.Form   <System.Diagnostics.DebuggerNonUserCode()> _   Public Sub New()     MyBase.New()     'This call is required by the Windows Form Designer.     InitializeComponent()   End Sub   'Form overrides dispose to clean up the component list.   <System.Diagnostics.DebuggerNonUserCode()> _   Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)     If disposing AndAlso components IsNot Nothing Then       components.Dispose()     End If     MyBase.Dispose(disposing)   End Sub   'Required by the Windows Form Designer   Private components As System.ComponentModel.IContainer   'NOTE: The following procedure is required by the Windows Form Designer   'It can be modified using the Windows Form Designer.   'Do not modify it using the code editor.   <System.Diagnostics.DebuggerStepThrough()> _   Private Sub InitializeComponent()     components = New System.ComponentModel.Container()     Me.Text = "Form1"   End Sub End Class

Form1クラスが定義されているもう1つのファイル（Form1.Designer.vb）の内容

　ここでポイントになるのは、1行目のクラス定義の先頭に付いているPartialキーワードである。このキーワードが付加されたクラスはパーシャル・クラスとなり、複数のファイルに分散した複数のクラス定義は、最終的に合成されて1つのクラスとなる（Partialキーワードは分散して存在するすべてのクラス定義のどれか1つに付いていればよい）。

　このようにVisual Basic 2005では、クラスをパーシャル・クラスに進化させることにより、VB.NETでの改良点をすべて維持したうえで、VB 6 0より見劣りしていた部分を補完したわけである。

ASP.NETアプリケーションはどうか？

　ここまではWindowsアプリケーションの話だったが、ASP.NETのWebアプリケーションの場合はどうだろうか。具体的なコードは割愛するが、VS.NET 2003では、ASP.NETアプリケーションにも書き換えてはならないコードが含まれていた。これもVisual Basic 2005になるとパーシャル・クラスで分離してくれるのだろうか。

　それを確認するために、Visual Web Developer 2005 Express Editionのベータ版で、Visual BasicのASP.NET Webサイトのプロジェクトを新規作成してみた。そして、Webフォームのコードを表示させてみると、やはりパーシャル・クラスを用いた（Partialキーワードを含む）コードが表示された。

Partial Class Default_aspx End Class

Visual Web Developer 2005 Expressが自動生成するWebフォームのためのコード

　Windowsアプリケーションと同様、書き換えてはならないコードが含まれておらず、以前に比べてより安全で見やすくなったことが分かる。

　では、Windowsアプリケーションと同じように、統合開発環境からは見えない別のクラス定義ファイルが存在するのだろうか。つまり、Form1.vbに対応するForm1.Designer.vbというファイルがあったように、このコードを含むDefault.aspx.vbというファイルに対応するDefault.aspx.Designer.vbというようなファイルがあるのだろうか。

　結論からいえば、そのようなファイル名のファイルはプロジェクトに含まれていない。しかし、これは「ファイルが存在しない」ということとイコールではない。ASP.NETというシステムは、プログラマから見えるソース・コードとは別に、多数のコードを自動生成するという凝った構造を取っていて、その段階で生成されるコードには、それに対応するコードが含まれる。それらは通常プログラマに対して隠されているため、見る機会はほとんどないだろう。しかし、隠されているだけであって「存在しない」わけではない。

　このように、Visual Basic 2005では、通常見る必要のない部分が別のファイルに分離され、ソース・コードが非常に見やすくなるのである。これまでのVB.NETに首をひねっていたあなたも、ぜひVisual Basic 2005に期待しようではないか！！

　

「Visual Basic 2005 ここが便利！」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）