C# 名前空間チュートリアル
―― スクリーンショット 1 枚で「using」のしくみまで体験する ――
対象:変数・クラスを習ったばかりの初学者
ゴール:
- SampleBlog.Models.Person というクラスを 別フォルダーに置く
 - Program.cs から using SampleBlog.Models; で呼び出す
 - 「なぜ動く?」「なぜエラーにならない?」を説明できるようになる
 
- 1. 完成例を先に確認しよう(スクショ付き)
- 1.1. プロジェクト作成手順
 - 1.2. 1. スクリーンショットで確認できる 3 つの事実
 - 1.3. 2. “箱と住所” でイメージしよう
 - 1.4. 3. 手を動かしてみる(5 分実習)
 - 1.5. 4. どこで区切る?命名ルール早見表
 - 1.6. 5. よくある質問(FAQ)
 - 1.7. 6. 仕上げ課題(自宅学習用)
 - 1.8. 1. Article クラスを追加して表示する
 - 1.9. Program.cs への追加
 - 1.10. 2. namespace をわざと誤字にすると?
 - 1.11. 3. Utilities フォルダーに日時クラスを追加して using で呼び出す
 - 1.12. Program.cs への追加
 - 1.13. まとめ
 
 - 2. まとめ
 
完成例を先に確認しよう(スクショ付き)
プロジェクト作成手順
- コンソール アプリ を選択
- ソリューション名 SampleNameSpace
 - プロジェクト名 SampleBlog
 
 

1. スクリーンショットで確認できる 3 つの事実
| 画面 | ファイル | namespace 宣言 | メモ | 
|---|---|---|---|
| 左 | Person.cs(Models フォルダー) | SampleBlog.Models | Person クラスを定義 | 
| 右 | Program.cs | SampleBlog | Main メソッドから new Person() | 
| 右上 | using SampleBlog.Models; | ― | Person を短く呼び出すための 1 行 | 
ポイント
- 物理フォルダー (Models) と 論理フォルダー (namespace) は一致させると分かりやすい。
 - どちらのファイルも 同じプロジェクト 内なので、internal でも参照できる。
 
2. “箱と住所” でイメージしよう
┌─ SampleBlog      ← プロジェクト(= DLL/EXE の単位)
│
├─ namespace SampleBlog.Models   ← 住所①
│   └─ Person クラス
│
└─ namespace SampleBlog         ← 住所②
    └─ Program クラス
- プロジェクトは “建物”
 - namespace は “住所”
 - クラス は “部屋”
 
using SampleBlog.Models; を書くと、Program は 隣の住所を地図に登録 したことになり、
Person という部屋を 部屋番号抜き で呼べるわけです。
3. 手を動かしてみる(5 分実習)
- Models フォルダーを右クリック → クラス → Person.cs
 - ファイル先頭に
 
namespace SampleBlog.Models
{
    internal class Person
    {
        public string Name { get; set; } = string.Empty;
    }
}
- Program.cs を開き、最上部に
 
using SampleBlog.Models;
- を追加。Main に下記 2 行を挿入して実行。
 
var author = new Person { Name = "Hideaki" };
Console.WriteLine(author.Name);   // → Hideaki
- 成功したら using を消してビルド → CS0246 エラーになるのを確認。今度は完全修飾名で書き換えてみよう:
 
var author = new SampleBlog.Models.Person();
4. どこで区切る?命名ルール早見表
| 階層 | 例 | 意味 | 
|---|---|---|
| 会社名・製品名 | SampleBlog | 他社 DLL と衝突しない | 
| サブドメイン | Models / Services / UI | 機能別に整理 | 
| 詳細機能 | Auth / Blog など | 必要に応じて深掘り | 
避けたい例
- NameSpace1, SubNameSpace2 … 意味が伝わらない
 - Common, Utils だけ … 後で「全部ここ」に膨れあがる
 
5. よくある質問(FAQ)
| 質問 | 回答 | 
|---|---|
| Q. public にしなくても呼べるの? | 同じアセンブリ (.exe / .dll) 内なら internal で OK。別プロジェクトにするときは public が必要。 | 
| Q. フォルダー名と namespace がズレたら? | コンパイルは通るが、開発者が迷子になる。修正推奨。 | 
| Q. 同名クラスが 2 つあると? | コンパイラが曖昧と判断し CS0104。完全修飾名で区別するか、設計を見直す。 | 
6. 仕上げ課題(自宅学習用)
- Models に Article クラスを追加。Title と Body プロパティを持たせ、Program から表示してみよう。
 - namespace を わざと誤字 (SampleBolg.Models) にすると何が起きるか?
 - もう一つ Utilities フォルダーを作り、namespace SampleBlog.Utilities で日時を返すクラスを作成。using で呼び出してみよう。
 
以下は、記事の「6. 仕上げ課題(自宅学習用)」で提示されている3つの課題それぞれに対する “模範解答” 例です。いずれも .NET 8 / C# 13 のコンソール アプリ を想定しています。
1. Article クラスを追加して表示する
Article.cs(Models フォルダー)
namespace SampleBlog.Models
{
    /// <summary>
    /// 記事を表すドメイン クラス。
    /// </summary>
    internal class Article
    {
        public string Title { get; set; } = string.Empty;
        public string Body  { get; set; } = string.Empty;
        public override string ToString() => $"#{Title}\n{Body}";
    }
}
Program.cs への追加
using SampleBlog.Models;
var article = new Article
{
    Title = "名前空間チュートリアルを読んで",
    Body  = "using が “地図登録” という説明が腑に落ちました!"
};
Console.WriteLine(article);
実行結果
# 名前空間チュートリアルを読んで
using が “地図登録” という説明が腑に落ちました!
ポイント
- internal でも同一プロジェクト内なので参照可。
 - ToString() をオーバーライドして表示用フォーマットを一カ所に集約。
 
2. namespace をわざと誤字にすると?
誤字版 Article.cs
namespace SampleBolg.Models   // ← “Blog” が “Bolg”
{
    internal class Article { }
}
Program.cs
using SampleBlog.Models;   // 正しい namespace
var a = new Article();
ビルド エラー
CS0246: 型または名前空間名 'Article' が見つかりませんでした
(are you missing a using directive or an assembly reference?)
さらに using SampleBolg.Models; と誤った using を書くと CS0246 に加え CS8019(不要な using)も発生。名前空間とフォルダー名を揃える大切さを体感できます。
3. Utilities フォルダーに日時クラスを追加して using で呼び出す
DateProvider.cs(Utilities フォルダー)
namespace SampleBlog.Utilities
{
    /// <summary>現在日時を提供するユーティリティ。</summary>
    public static class DateProvider
    {
        public static DateTime NowJst() => DateTime.Now;             // 単純版
        public static DateTime TodayJst() => DateTime.Today;
    }
}
public にした理由
Utilities は将来 別プロジェクト(例:共通 DLL)へ切り出す可能性があり、そのときも参照できるように外部公開を前提にしておくと移行が楽です。
Program.cs への追加
using SampleBlog.Utilities;
Console.WriteLine($"今日は {DateProvider.TodayJst():yyyy/MM/dd} です");
実行例
今日は 2025/07/22 です
まとめ
- 課題 1: 新しいドメイン クラスを追加し、using による短い参照を確認。
 - 課題 2: 名前空間の誤字 → CS0246/ CS8019 エラーで“論理住所”の重要性を体験。
 - 課題 3: Utilities という “別サブドメイン” を設け、公開レベルの違いも学習。
 
これらを一通り試せば、「namespace の設計・運用と using の働き」 を実務レベルで理解できます。次のステップとして、Article と Utilities を 別プロジェクト(クラス ライブラリ)に抽出し、DLL 参照とアクセス修飾子の違いを確かめてみましょう。
まとめ
- namespace=論理フォルダー。フォルダー構成とそろえると迷わない
 - using は 地図登録。長い “住所” を 1 行で短縮
 - 同じプロジェクトなら internal でも呼べるが、別プロジェクトに分けたら public が必須
 
この 3 ステップを押さえれば、実務で遭遇するほとんどの「名前空間って何?」は解決できます。次はプロジェクトを 2 つに分けて DLL 参照にも挑戦してみましょう。






ディスカッション
コメント一覧
まだ、コメントがありません