連載
プロフェッショナルVB.NETプログラミング
第18回 名前空間とImports文(後編)
(株)ピーデー
川俣 晶
2002/09/28
|
|
フォームと名前空間
ここまで来ればすでに理解できていると思うが、Namespace文を用いずに記述されたクラスなども、実際には、プロジェクト名と同じ名前空間に属している。そのことはオブジェクト・ブラウザで容易に確認することができる。例えば、フォームを定義するForm1クラスは、プロジェクト名と同じ名前の名前空間に属している。そこで、プロジェクト名がaなら、Form1を、a.Form1と記述してもコンパイラは理解する。
しかし、以下のようにスタートアップ・フォームとなっているForm1を勝手なNamespace文で囲むとコンパイラはエラーを引き起こす。
1: Namespace MySpace1
2: Public Class Form1
3: Inherits System.Windows.Forms.Form
4:
5: #Region " Windows フォーム デザイナで生成されたコード "
6:
7: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
8: Trace.WriteLine("Form1_Load called")
9: End Sub
10: End Class
11: End Namespace
|
|
スタートアップ・フォームとなっているForm1を独自の名前空間で囲ったVB.NETのサンプル・プログラム5(コンパイル・エラーとなる) |
このソースをコンパイルすると、「'Sub Main' が、'Sample008n.Form1' に見つかりませんでした。」というエラーメッセージが出力される。このようなエラーが出力される理由は、プロジェクトのプロパティで指定されているスタートアップ・フォームがSample008n.Form1であるにも関わらず、ソース上でNamespace文を挿入して名前空間を含む完全な名前(完全限定名という)を変更してしまったことにある。これを解決するには、スタートアップ・フォームの名前を変更するか、Namespace文を取り除く必要がある。
クラスの別名を宣言するImports文
Imports文は、名前空間名の一部または全部だけでなく、クラス名の別名も宣言できる。以下は、クラスMyClass1の別名としてaという名前を宣言した例である。
1: Imports a = Sample009n.MyClass1
2:
3: Public Class MyClass1
4: Public Shared Sub MyMethod1()
5: Trace.WriteLine("MyClass1.MyMethod1 called")
6: End Sub
7: End Class
8:
9: Public Class MyClass2
10: Inherits a
11: End Class
12:
13: Public Class Form1
14: Inherits System.Windows.Forms.Form
15:
16: #Region " Windows フォーム デザイナで生成されたコード "
17:
18: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
19: a.MyMethod1()
20: MyClass2.MyMethod1()
21: End Sub
22: End Class
|
|
Imports文によりクラス名の別名を宣言したVB.NETのサンプル・プログラム6 |
これを実行すると以下のようになる。
1: MyClass1.MyMethod1 called
2: MyClass1.MyMethod1 called
|
|
サンプル・プログラム6の実行結果 |
まず注目すべき点はソースの10行目である。 「Inherits a」と書かれているが、「a」は当然MyClass1(フルネームはSample009n.MyClass1、Sample009nはこのプログラムのプロジェクト名)の別名として機能しており、MyClass2はMyClass1を継承している。そのことは、20行目を見るとはっきりと分かる。MyClass2を通して、MyClass1のメソッドを呼び出すことができている。また、19行目では、「a」が完全にMyClass1と等価のキーワードとして機能していることが分かるだろう。
クラス・ライブラリ活用と関連する名前空間
クラス・ライブラリはプログラムで活用できる材料の宝庫である。しかし、これを活用するには、名前空間の知識が必須である。.NET Frameworkのクラス・ライブラリは、いくつにも分割されており、参照の追加で個々のクラス・ライブラリをプロジェクトから利用可能にする必要がある。しかし、参照の追加はあくまで参照を追加するだけで、ソース・コードからクラス・ライブラリのクラスなどを指定するには、名前空間名を含む長い名前(完全限定名)を記述しなければならない。これが面倒だと思うなら、Imports文でデフォルトの名前空間名としてその名前空間名を追加記述してやれば、名前空間名をいちいち記述する必要はなくなる。
以下は実際に、System.Text名前空間のStringBuilderクラスを利用した例である。
1: Imports System.Text
2: Imports System.Net
3:
4: Public Class Form1
5: Inherits System.Windows.Forms.Form
6:
7: #Region " Windows フォーム デザイナで生成されたコード "
8:
9: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
10: Dim sb As StringBuilder
11: sb = New StringBuilder()
12: Dim i As Integer
13: For i = 0 To 1000
14: sb.Append(i.ToString())
15: sb.Append(" ")
16: Next
17: Trace.WriteLine(sb.ToString().Substring(0, 100))
18: Trace.WriteLine(Dns.GetHostName())
19: End Sub
20: End Class
|
|
.NET Frameworkクラス・ライブラリをImports文で指定したVB.NETのサンプル・プログラム7 |
これを実行すると以下のようになる。
1: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
2: tailmon3
|
|
サンプル・プログラム7の実行結果 |
まずソース・コードの1行目を見ていただきたい。ここで、System.Textをデフォルトの名前空間名としている。なお、Systemは1つの名前空間名、System.Textはそれとは異なる別の独立した名前空間名であることに注意が必要である。この2つが示すものは、互いに何の関係もない別個の名前空間である。
1行目のImports文のおかげで、10行目のDim文などで、StringBuilderクラスの名前は名前空間名抜きで記述することができる。StringBuilderクラスは、Appendメソッドを用いて文字列を高速に追加する機能を提供する。ここでは、0から1000までの数字を示す文字列を次々に追加している。17行目では、その結果の最初の100文字だけを出力している。
さて、このソースではもう1つ、2行目でSystem.Net名前空間もデフォルトの名前空間に指定している。その効能は、18行目に現れている。DnsはSystem.Net名前空間に含まれるクラスの名前だが、Imports文の効能により、いちいちSystem.Netという名前空間名を記述せずに利用できている。なお、結果に表示されている“tailmon3”とは、このサンプル・プログラムを実行したPCのホスト名である。System.Net.Dns.GetHostNameメソッドは、自分自身のホスト名を返す機能を持ったメソッドである。(が、DNSに詳しい人なら実用上ちょっと問題があることが分かると思う)
次回予告
次回は継承とボリモーフィズムに関する解説を予定している。
Insider.NET 記事ランキング
本日
月間