|
|
連載
改訂版
プロフェッショナルVB.NETプログラミング
Chapter 08 クラス・ライブラリ
株式会社ピーデー
川俣 晶
2004/05/27 |
|
|
クラス・ライブラリを使用するには、いくつか理解しておくべき点がある。特に、名前空間名とライブラリのアセンブリ・ファイルは、似たような名前を持つこともあるため、その違いと、それに対処する方法はしっかりと把握しなければならない。一例として、電子メール送信機能のサンプル・プログラムを取り上げてみよう(リスト8-3)。
1: Private Sub SendEMail(ByVal msg As String)
2: Const from As String = "system@piedey.co.jp"
3: Const mailto As String = "hitomi@piedey.co.jp"
4: Const subject As String = "Sample Mail"
5: System.Web.Mail.SmtpMail.Send(from, mailto, subject, msg)
6: End Sub
7:
8: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
9: SendEMail("Hello!")
10: End Sub
|
|
リスト8-3 電子メール送信機能を記述したプログラム
|
このサンプル・プログラムをビルドするには、System.Web.dllというライブラリ(電子メール機能を利用するためのもの)への参照を追加する必要がある。
|
●図8-4 Visual Studio .NETの[参照の追加]ダイアログ |
しかし、ここで使用しているSmtpMailクラスの名前空間は、System.Web.Mailであって、System.Webではない。それなのに、System.Webへの参照を追加するだけでよいのだろうか?
この問いは根本的な誤解を含んでいる。というのも、System.Webというライブラリ(アセンブリ)の名前と、System.Webという名前空間は、直接的には結びついていないのだ。そのことは、オブジェクトブラウザを見るとすぐに分かる。
例えば、ここで問題になっているSmtpMailクラスを見てみよう。
|
●図8-5 Visual Studio .NETのオブジェクトブラウザ |
System.Webは、その内部にSystem.Webだけでなく、System.Web.Caching、System.Configurationなどの名前空間のクラスも持っていて、もちろん、System.Web.Mail名前空間のクラスも含んでいる。つまり、アセンブリSystem.Webを参照するだけで、System.Web.Mail名前空間が利用可能になるわけである。
しかし、逆に考えるとどうだろうか。例えば、System.Web.Mail名前空間のクラスを使いたいと思った場合、どのアセンブリを参照に追加すればよいだろうか? それを判断すべき単純なルールはない。そもそも、ある名前空間に対応するアセンブリが一意に決まるとは限らない。例えば、オブジェクトブラウザでアセンブリmscorlibを見ると、System名前空間を含んでいることが分かる。ところが、これとは別にSystemというアセンブリもあって、これにもSystem名前空間が含まれている。
|
●図8-6 同じ名前の名前空間「System」が、異なる2つのアセンブリに存在している |
あるクラスを利用したいときに、どのアセンブリを参照に追加すべきかを判断する最も正しい方法は、クラス・ライブラリのリファレンスを読むことである。例えばSmtpMailクラスなら、以下のようにリファレンスを参照する。
|
●図8-7 クラス・ライブラリ(SmtpMailクラス)のリファレンス画面 |
ここで、必要条件のアセンブリの記述を見れば、必要なアセンブリの名前が分かるという仕組みである。
クラス・ライブラリは、プログラムで活用できる材料の宝庫である。しかし、これを活用するには、名前空間の知識が必須である。.NET Frameworkのクラス・ライブラリは、いくつにも分割されており、参照の追加で個々のクラス・ライブラリをプロジェクトから利用可能にする必要がある。しかし、参照の追加はあくまで参照を追加するだけで、ソース・コードからクラス・ライブラリのクラスなどを指定するには、名前空間名を含む長い名前(完全限定名)を記述しなければならない。これが面倒だと思うなら、Importsステートメントでデフォルトの名前空間名として追加記述してやれば、名前空間名をいちいち記述する必要はなくなる(デフォルトの名前空間を指定するImportsステートメントを参照)。
リスト8-8は、実際にSystem.Text名前空間のStringBuilderクラスを利用した例である(StringBuilderクラスについては、クラス・ライブラリを使ってみるを参照)。
1: Imports System.Text
2: Imports System.Net
3:
4: Public Class Form1
5: Inherits System.Windows.Forms.Form
6:
7: …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
|
|
リスト8-8 .NET Frameworkクラス・ライブラリをImportsステートメントで指定したプログラム
|
これを実行すると次のようになる。
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
|
|
リスト8-9 リスト8-8の実行結果
|
まず、ソース・コードの1行目を見ていただきたい。ここで、System.Textをデフォルトの名前空間名としている。なお、Systemは1つの名前空間名、System.Textはそれとは異なる別の独立した名前空間名であることに注意が必要である。この2つが示すものは、互いに何の関係もない別個の名前空間である。
10行目のDim文などで、StringBuilderクラスの名前は名前空間名抜きで記述されているが、これは1行目のImportsステートメントのおかげである。StringBuilderクラスは、Appendメソッドを用いて文字列を高速に追加する機能を提供する。ここでは、0から1000までの数字を示す文字列を次々に追加している。17行目では、その結果の最初の100文字だけを出力している。
さて、このソースではもう1つ、2行目でSystem.Net名前空間もデフォルトの名前空間に指定している。その効能は、18行目に現れている。DnsはSystem.Net名前空間に含まれるクラスの名前だが、Importsステートメントの効能により、いちいちSystem.Netという名前空間名を記述せずに利用できている。なお、結果に表示されている「tailmon3」とは、このサンプル・プログラムを実行したPCのホスト名である。System.Net.Dns.GetHostNameメソッドは、自分自身のホスト名を返す機能を持ったメソッドである(が、DNSに詳しい人なら実用上ちょっと問題があることが分かると思う)。