C#

最終更新日: 2022.12.19 (公開: 2022.12.16)

C#のusingはコーディング効率化に便利!機能と使い方・応用法を解説

C#のusingはコーディング効率化に便利!機能と使い方・応用法を解説

ここではC#の「using」に焦点を当てて、使い方や応用法を紹介します。「Usingディレクティブ」や「Usingエイリアスディレクティブ」などさまざまな種類がありますが、サンプルコード付きでわかりやすく解説しているので、ぜひご覧ください。

C#の「using」は、さまざまな場面でコーディングの効率化をサポートしてくれる、便利な機能です。しかし、usingには大きく分けて以下4種類のものがあるため、「どう使えばいいかわからない」という方も多いのではないでしょうか。

  • Usingディレクティブ
  • Usingエイリアスディレクティブ
  • Using静的ディレクティブ
  • Usingステートメント

いずれの機能も、うまく使いこなせばソースコードを簡潔化できます。usingは、基本的にはnamespace(名前空間)の指定なしで、内部のクラスにアクセスできるようにするための機能。一方、「アンマネージドリソース」を「マネージド環境下」に置くための機能も提供されています。

本記事では、C#のusingの種類やそれぞれの機能について、わかりやすいサンプルコード付きで解説します。今回ご紹介する内容をマスターすれば、C#のusingを自由に使いこなせるようになるので、ぜひご参考ください。

Usingディレクティブ:名前空間内のクラスを「完全修飾名」なしで使える

C#のusingの最も基本的な機能が「Usingディレクティブ」です。Usingディレクティブは、名前空間内のクラスを「完全修飾名」なしで使うための機能。Usingディレクティブを使用しない場合は以下のサンプルコードのように、クラスを呼び出すときは「名前空間+クラス名」の「完全修飾名」を指定する必要があります。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_samplecode

「System.Collections.Generic」や「System」など、クラスを呼び出すたびに名前空間を指定するのは面倒ですよね。そこで以下のように、Usingディレクティブを活用することで、名前空間内にあるクラスを完全修飾名なしで使えるようになります。

//サンプルプログラム
c#_using_samplecode

2つのソースコードを見比べてみると、Usingディレクティブを使うほうが簡潔なコードになっています。とくに「Listクラス」は名前空間名が長いので、usingディレクティブはぜひとも活用したいところです。

名前空間とは?クラスを種類ごとに分類するための機能

そもそも「名前空間(namespace)」とは、クラスを種類ごとに分類するための機能です。パソコンでファイルを管理するときは、「画像」や「音楽」など種類ごとにフォルダを分けて管理すると、使いやすくなりますよね。C#のソースコードでも同じように、以下の構文でクラスを名前空間で囲んで整理します。

c#_using_samplecode

なお、名前空間内のクラスにアクセスする場合は、「名前空間名.クラス名」のように「.(ドット)」を付けて指定する必要があります。これを「完全修飾名」と呼びます。名前空間の中にあるクラスは、名前空間を指定しなければアクセスできません。

名前空間を使う大きなメリットが、「クラス名の重複が可能になる」こと。C#ではクラス名の重複は認められていないため、ひとつのクラス名は1回しか使えません。しかし、以下のようにnamespaceで囲めば、「別物」として扱われるので名称の重複が認められます。

c#_using_samplecode

上記のサンプルコードでは、「First」と「Second」という2つの名前空間の内部に、「Testクラス」があります。クラスの名前が重複していますが、それぞれ名前空間で囲んでいるため、別物として扱われます。クラスの名前が重複したとき、名前空間で囲むようにすると、重複を避けるための名前をわざわざ考える必要がないので便利です。

「Global修飾子」を付ければプロジェクト全体に適用される

現在のC#では「Global Using ディレクティブ」も使えます。これは、Usingディレクティブに「global」という修飾子を付けることにより、プロジェクト全体で名前空間名を省略したアクセスが可能になるというもの。たとえば、以下のサンプルコードを見てみましょう。

//サンプルプログラム
c#_using_samplecode

上記のサンプルプログラムは動作しません。なぜなら「Program.cs」ファイルには、「using System;」が記載されておらず、完全修飾名なしで「WriteLineメソッド」が使えないからです。

「Other.cs」ファイルにはUsingディレクティブが使われていますが、その効果が及ぶのはあくまでOther.csのみ。一方で以下のように、Global Usingディレクティブを使用すると、Usingディレクティブの効果がプログラム全体に及ぶので、問題なく動くようになります。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_samplecode

重要なポイントは、「Other.cs」ファイル内に「global using System;」と記載していることです。これにより「Program.cs」ファイルでも、System名前空間に完全修飾名なしでもアクセスできるようになります。なお「global using ディレクティブ」は、通常のusingディレクティブの前にしか書けないので要注意。あとに書くとコンパイルエラーとなります。

Usingディレクティブの注意点3つ!

Usingディレクティブについて、知っておくべき知識や注意点を以下3つ解説します。

  • 名前空間名が分からないときは「オブジェクトブラウザー」でチェック!
  • Usingしすぎると「クラス名の衝突」が起きることが増える
  • クラス名が重複したときは「完全修飾名」が必要になる

名前空間名が分からないときは「オブジェクトブラウザー」でチェック!

C#では、クラスにアクセスするときは「名前空間」の名称を知っておく必要があります。Usingディレクティブを使う場合でも、そもそも「どの名前空間に属しているか」わからなければ、Usingディレクティブに追加することもできません。

クラスの名前空間がわからない場合は、以下の手順で「オブジェクトブラウザー」を使って確認しましょう。今回は「List」がどの名前空間に属するかわからない場合を例に解説します。

object browser

画面上部のメニューから「表示」→「オブジェクトブラウザー」と進むと、別の画面に遷移してオブジェクトブラウザーが開きます。これは、C#の標準機能に関するオブジェクトのデータを、細かく調べることができる機能です。

object browser

上部の検索窓に、名前空間名を探したいクラス名を入力すると、以下の画像のように「完全修飾名」が表示されます。

object browser

上記は「List」を検索したもので、クラス名「List」の前にあるものがすべて名前空間名となります。この場合は「System.Collections.Generic」なので、プログラム先頭に「using System.Collections.Generic;」と記載すれば問題ありません。クラスの名前空間がわからない場合は、ぜひこの手順でオブジェクトブラウザーを活用しましょう。

Usingしすぎると「クラス名の衝突」が起きることが増える

C#のUsingディレクティブは、ソースコードの簡潔化に役立つ機能ですが、使いすぎると「クラス名の衝突」が起きることが増えてしまいます。たとえば以下のように、クラス名が重複している場合は、Usingディレクティブを使うとアクセスできず、コンパイルエラーが表示されます。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_result

上記の画像のように、「あいまいな参照です」というエラーが表示されます。これは、完全修飾名を省いた場合に「Testクラスが2つある」ことになり、「どちらにアクセスしたいか」をコンパイラが判断できないからです。

Usingディレクティブは便利ですが、あまり多くの場所で使いすぎると、このような名前の衝突が起きます。使用頻度の高い名前空間はUsingディレクティブを使い、使用頻度が低い、もしくはクラス名が重複している場合は完全修飾名を使うなどの対策が必要です。

クラス名が重複したときは「完全修飾名」が必要になる

Usingディレクティブを使って、名前空間内部のクラス名が衝突してしまった場合は、Usingディレクティブを使わない場合と同じく「完全修飾名」が必要になります。詳細は以下のサンプルコードのとおりです。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_result

もしくは以下のサンプルコードのように、片方だけにUsingディレクティブを使って、もう一方には完全修飾名を使うことも可能です。

//サンプルプログラム
c#_using_samplecode

どちらを使うかはケースバイケースで考えましょう。もしくはこのあと紹介するように、「Usingエイリアスディレクティブ」を使うことも可能です。多くの場合は、Usingエイリアスディレクティブを使うほうが、少し便利な結果になるでしょう。

Usingエイリアスディレクティブ:クラス名が重複する名前空間に「別名」を付ける

Usingエイリアスディレクティブ:クラス名が重複する名前空間に「別名」を付ける

先ほどご紹介したように、Usingディレクティブを使うと、クラス名が重複してしまうことがあります。しかし、わざわざ完全修飾名を使うというのは不便なことも多いでしょう。そこで便利なのが「Usingエイリアスディレクティブ」です。Usingエイリアスディレクティブは、クラス名が重複する名前空間に「エイリアス(別名)」を付けることができる機能で、構文は以下のとおりです。

c#_using_samplecode

上記の構文で付けたエイリアスを使ってクラスにアクセスすれば、クラスにアクセスできるようになります。いわば名前空間に別名を付けて、ソースコード入力の手間を省くための機能ということです。詳細は以下のサンプルコードのとおりです。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_result_10

以上のように、エイリアスを付ければクラス名が重複していても大丈夫です。しかし結局のところは、エイリアスであっても名前空間を書く必要があることには変わりはありません。長い名前空間を短く省略できるという点では有利ですが、Usingディレクティブでしっかり省略したいという場合は、そもそもクラス名を重複させないことが重要になります。

エイリアスと同名のクラスがある場合は「エイリアス修飾子」を使う

名前空間にエイリアスを付ければ、クラス名が重複していても問題なくアクセスできます。しかし、以下のようにエイリアス名と重複するクラスがある場合は、コンパイルエラーとなってしまいます。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_result_11

上記のような事例は、たとえば複数人でプログラムを作成しているプロジェクトで、自分以外の誰かが新しいクラスを追加して起きる可能性があります。このような場合は、エイリアスを使ったクラスへのアクセス時に、「エイリアス修飾子」を使いましょう。

c#_using_result_

エイリアスの後ろの「.」が「::」に変えると、エイリアス修飾子が使えます。「::」はエイリアスの後ろにしか付けられないため、「::」の直前部分はエイリアスであることが確定するので、見た目の点でも明確でわかりやすいです。これで、同名のクラスがあとから追加されても問題ありません。詳細は以下のサンプルコードのとおりです。

//サンプルプログラム
c#_using_result_
//実行結果
c#_using_result_

Using静的ディレクティブ:クラス名なしで静的メソッドを呼び出せる

Using静的ディレクティブ:クラス名なしで静的メソッドを呼び出せる

クラス内部の「静的メソッド」には、「クラス名.静的メソッド名」という2段階のアクセスが必要になります。これはUsingディレクティブを使った場合も変わりません。しかし「Using静的ディレクティブ」を使えば、クラス名だけではなくクラス内部の「staticメソッド(静的メソッド)」を、クラス名なしでアクセスできます。

c#_using_result_

自作クラスはもちろん、標準ライブラリにも使える便利な機能です。たとえば、よくアクセスする静的メソッドがある場合は、Using静的ディレクティブを活用すれば、コーディングの手間を省くことができるでしょう。詳細は以下のサンプルコードのとおりです。

//サンプルプログラム
c#_using_result_
//実行結果
c#_using_result_

上記の例では、自作クラス「Math」だけではなく、System名前空間内の「Consoleクラス」にUsing静的ディレクティブを適用してみました。ただし、適用範囲が及ぶ範囲が広すぎると、名前衝突や混乱の原因になるため、あくまで自作クラスのみに留めておくといいでしょう。もちろん、名前の衝突が起きるとコンパイルエラーが表示されます。

Usingステートメント:リソースを自動的に解放してくれる便利機能

Usingステートメント:リソースを自動的に解放してくれる便利機能

最後にご紹介する「Usingステートメント」は、C#のUsingで最も便利な機能です。Usingステートメントは、「アンマネージドリソース」を自動的に破棄・解放してくれます。Usingステートメントについて、以下3つの観点から詳しく見ていきましょう。

  • 「マネージドリソース」と「アンマネージドリソース」の違い
  • 解放処理しなかったリソースにはアクセスできなくなる
  • アンマネージドリソースは「finally節」で「Closeメソッド」で解放する
  • 「Usingステートメント」を使えばCloseメソッドの呼び出しは不要
  • 変数宣言時にUsingステートメントを使えばさらに簡潔化できる

「マネージドリソース」と「アンマネージドリソース」の違い

C#では、インスタンス化されたオブジェクトは、使用後に「ガベージコレクション(ガベージコレクター)」が自動的に破棄・解放してくれます。C#では大半のオブジェクト・リソースはガベージコレクションが有効なので、「マネージドリソース」と呼ばれるものです。

しかし、ファイルアクセスやデータベースなどで使用する一部のリソースは、「アンマネージドリソース」つまりガベージコレクションが働きません。たとえば、ファイルは使い終わったら明示的に終了処理(クローズ)できるほうが何かと便利なので、プログラマー側が手動でリソースの使用権を破棄しないといけません。

この手順を行うと、ファイルリソースを使用した場合はファイルが開きっぱなし、つまりロックが掛かった状態のままですと、他のプログラムからアクセスできなくなるので注意しましょう。

解放処理しなかったリソースにはアクセスできなくなる

前述したとおり、C#で解放処理されなかった「アンマネージドリソース」には、もうアクセスできなくなってしまいます。アンマネージドリソースを手動で解放する意味について、実際に以下のプログラムで確認してみましょう。Cドライブ直下に「Testフォルダ」を作成し、その中に「Test.txt」という適当なファイルを作成してから、以下のソースコードを実行してみてください。

//サンプルプログラム
c#_using_result_
//実行結果
c#_using_samplecode

「Could not find file」と表示される場合は、ファイルの設置場所が誤っているので、再度ファイルの場所を見直してみましょう。上記のサンプルプログラムを実行すると、「The process cannot access the file」と表示されます。これは「ファイルにアクセスできない」ということです。

上記のサンプルコードでは、同じファイルを2回開いていますが、1回目を開いたあとにファイルリソースの解放処理を行っていません。つまり、リソースの使用権を破棄していないということです。そのため、もう一度同じファイルにアクセスしようとしたときに、アクセス不可の例外が発生します。

なお、アンマネージドリソースは「IDisposableインターフェース」を継承していることが特徴になります。そのため、IDisposableインターフェースを継承しているオブジェクトやリソースを使うときは、明示的な解放処理が必要だと考えておきましょう。

ちなみに、C#では「.NET」のさまざまな安全機能があるため、たとえリソースの解放をしなかったとしても、プログラム終了時には自動的に解放される仕様になっています。そのため、アンマネージドリソースの解放を忘れたとしても、コンピューター自体からアクセス不能になるわけではありません。

しかし、プログラム動作中は2度とアクセスできなくなりますし、ほかのプログラムがそのファイルを開く際にもエラーが出ます。そのため、アンマネージドリソースの解放処理は、しっかり行っておきましょう。

アンマネージドリソースは「finally節」で「Closeメソッド」で解放する

アンマネージドリソースは、「finally節」で「Closeメソッド」を呼ぶことで、破棄・解放処理を行います。ちなみにfinally節とは、「try-catch文」で「例外の有無に関わらず実行する処理」を記載する部分のことです。リソースの解放は、エラーが発生した場合でも行う必要があるため、finally節で記載するのが適切です。以下のサンプルコードで詳細を確認しておきましょう。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_samplecode

上記のように問題なく実行できます。重要なポイントは、「finally節」の内部でファイルストリームオブジェクトの「Closeメソッド」を呼び出し、アンマネージドリソースを解放していることです。この手順により、ファイルの使用権が放棄されて、ほかのプロセスからアクセスできるようになります。

ただし、そもそもファイルストリームオブジェクトが生成されていない場合は、「NULLポインタ」が入っているためアクセスしてはいけません。そのため、事前にNULLチェックを行っておく必要があります。

「Usingステートメント」を使えばCloseメソッドの呼び出しは不要

アンマネージドリソースを使用するたびに、Closeメソッドなどを呼び出すのは面倒なのではないでしょうか。以下の構文で「Usingステートメント」を使えば、finally節でCloseメソッドなどを呼び出す必要がなくなります。

c#_using_samplecode

つまり、アンマネージドリソースをインスタンス化する部分を「using」で囲み、実際にリソースを使用する部分をブロックで囲めばいいということです。具体的なサンプルコードは以下のとおりです。

//サンプルプログラム
c#_using_samplecode
//実行結果
c#_using_samplecode

上記のように記載すれば、finallyそのものが不要になるので、ソースコードが大幅に簡潔化します。なお、複数のアンマネージドリソースを同時に生成する場合は、以下のサンプルコードのようにusingステートメントを縦に並べて記載すれば問題ありません。なお、テキストファイルには以下のように、適当な文章を入力してください。

//Test.txt
c#_using_samplecode
//サンプルプログラム
c#_using_samplecode_
//実行結果
c#_using_samplecode_

変数宣言時にUsingステートメントを使えばさらに簡潔化できる

アンマネージドリソースの変数宣言時にUsingステートメントを使えば、ソースコードをさらに簡潔化することができます。アンマネージドリソースのUsingステートメントの構文は以下のとおりです。

resorce

つまり、通常どおりリソースを生成するときに、先頭に「using」を付ければいいだけということです。ただしこの記法を使用する場合は、変数宣言と生成を個別に行うことはできないので、宣言と生成を同時に行う必要があります。詳細を以下のサンプルコードで確認しましょう。

//サンプルプログラム
c#_using_samplecode
//実行結果

このように、ソースコードが非常にスッキリするため、基本的にはこちらの書き方を推奨します。アンマネージドリソースを使用するときは、ぜひ活用してみてください。

C#の「Using」を便利に活用してソースコードを簡潔化しよう!

C#の「Using」にはさまざまな機能があり、その代表的な種類は「Usingディレクティブ」「Usingエイリアスディレクティブ」「Using静的ディレクティブ」「Usingステートメント」の4つがあります。Usingディレクティブ関連は、名前空間内にあるクラスや、クラス内にある静的メソッドを、簡単に呼び出せるようにするための機能です。

ただし、Usingディレクティブを使用する場合は、内部のクラス名に名前衝突が起きるとコンパイルエラーが表示されます。その場合は一方にのみUsingディレクティブを使用したり、そもそも名前を変更したり、もしくはエイリアスを付けるなどの対策が必要です。

Usingステートメントは、C#のアンマネージドリソースを自動的に解放してくれる便利機能です。finallyブロック内で解放処理を書く必要がなくなるので、ソースコードを大幅に簡潔化できます。この機会にぜひ、C#のさまざまなusingを活用して、より効率的なソースコードを書けるようにしましょう。

アクセスランキング 人気のある記事をピックアップ!

    コードカキタイがオススメする記事!

    1. 子供におすすめのプログラミングスクール10選!学習メリットや教室選びのコツも紹介

      2022.01.06

      子供におすすめのプログラミングスクール10選!学習メリットや教室選びのコツも紹介

      #プログラミングスクール

    2. 【完全版】大学生におすすめのプログラミングスクール13選!選ぶコツも詳しく解説

      2022.01.06

      【完全版】大学生におすすめのプログラミングスクール13選!選ぶコツも詳しく解説

      #プログラミングスクール

    3. 【未経験でも転職可】30代におすすめプログラミングスクール8選!

      2022.01.06

      【未経験でも転職可】30代におすすめプログラミングスクール8選!

      #プログラミングスクール

    4. 初心者必見!独学のJava学習方法とおすすめ本、アプリを詳しく解説

      2022.01.06

      初心者必見!独学のJava学習方法とおすすめ本、アプリを詳しく解説

      #JAVA

    5. 忙しい社会人におすすめプログラミングスクール15選!失敗しない選び方も詳しく解説

      2022.01.06

      忙しい社会人におすすめプログラミングスクール15選!失敗しない選び方も詳しく解説

      #プログラミングスクール

    1. 【無料あり】大阪のおすすめプログラミングスクール14選!スクール選びのコツも紹介

      2022.01.06

      【無料あり】大阪のおすすめプログラミングスクール14選!スクール選びのコツも紹介

      #プログラミングスクール

    2. 【目的別】東京のおすすめプログラミングスクール20選!スクール選びのコツも徹底解説

      2022.01.06

      【目的別】東京のおすすめプログラミングスクール20選!スクール選びのコツも徹底解説

      #プログラミングスクール

    3. 【無料あり】福岡のおすすめプログラミングスクール13選!選び方も詳しく解説

      2022.01.06

      【無料あり】福岡のおすすめプログラミングスクール13選!選び方も詳しく解説

      #プログラミングスクール

    4. 【徹底比較】名古屋のおすすめプログラミングスクール13選!選び方も詳しく解説

      2022.01.06

      【徹底比較】名古屋のおすすめプログラミングスクール13選!選び方も詳しく解説

      #プログラミングスクール

    5. 【徹底比較】おすすめのプログラミングスクール18選!失敗しない選び方も徹底解説

      2022.01.06

      【徹底比較】おすすめのプログラミングスクール18選!失敗しない選び方も徹底解説

      #プログラミングスクール