先生と生徒の会話形式で理解しよう

生徒

「C#で複数のクラスを作ったとき、クラス同士がバラバラになってわかりづらいんですが、何か良い方法はありますか？」

先生

「とてもよい疑問ですね。C#では、クラス同士の依存関係をできるだけ減らすことが大切です。依存関係を減らすことで、プログラムがわかりやすくなり、修正や再利用もしやすくなります。」

生徒

「依存関係ってなんですか？」

先生

「依存関係とは、あるクラスが他のクラスに強く結びついていて、そのクラスが変更されると影響を受けるような状態のことです。今から、それを防ぐ方法をわかりやすく説明していきましょう。」

1. クラス間の依存関係とは？

クラス間の依存関係とは、一言で言うと「あるクラスが動作するために、別の特定のクラスを必要としている状態」のことです。プログラミングの世界では、これを「密結合（みつけつごう）」と呼び、あまり好ましくない状態とされています。

例えば、料理ロボット（クラスA）が、特定のメーカーのフライパン（クラスB）を直接手に持って固定されている場面を想像してみてください。フライパンが古くなって交換したくても、ロボットの手と一体化しているため、ロボットごと改造しなければなりません。これが「依存関係が強い」状態です。

具体的なダメな例をコードで見てみましょう。ここでは、車（Car）がガソリンエンジン（GasolineEngine）を自分の中で作ってしまっています。


// ガソリンエンジンのクラス
public class GasolineEngine
{
    public void Start()
    {
        Console.WriteLine("ガソリンエンジンが始動しました。");
    }
}

// 車のクラス
public class Car
{
    private GasolineEngine engine;

    public Car()
    {
        // クラスの中で直接「new」して生成している
        // これが「CarはGasolineEngineに依存している」状態です
        this.engine = new GasolineEngine();
    }

    public void Drive()
    {
        engine.Start();
        Console.WriteLine("車が走り出しました。");
    }
}

この設計の最大の問題は、もし「電気エンジン（ElectricEngine）」に載せ替えたくなった時、Carクラスの中身を書き直さなければならない点です。本来、車（Car）は「走ること」が仕事であり、「エンジンの具体的な作り方」まで詳しく知っている必要はありません。

このように、newを使って他のクラスを直接呼び出すと、部品同士がガッチリくっつきすぎてしまい、柔軟性が失われてしまうのです。

2. なぜ依存関係を減らすべきなのか？

クラス同士が強く結びついた「密結合」な状態は、システムが大きくなるにつれて大きな壁となります。依存関係を最小限に抑える「疎結合」な設計が求められる主な理由は、以下の3つのリスクを回避するためです。

ドミノ倒しのような修正（変更の波及）：あるクラスを一行書き換えただけで、全く関係のない場所でエラーが出る。これを防ぎ、安全に改修できるようにします。
テストの自動化が困難になる：特定のクラスが動かないとテストができないため、不具合の発見が遅れます。
再利用のハードルが高まる：便利な機能を他のアプリでも使いたいのに、依存している大量のクラスも一緒にコピーしなければ動かないという事態に陥ります。

具体的なイメージを持つために、プログラミング未経験の方でもわかる「お買い物プログラム」で、依存関係が強いと何が困るのかを見てみましょう。

ダメな例：特定の支払い方法に依存した設計


// 現金支払いクラス
public class CashPayment
{
    public void Pay(int amount)
    {
        Console.WriteLine(amount + "円を現金で支払いました。");
    }
}

// レジクラス
public class Cashier
{
    private CashPayment payment = new CashPayment();

    public void Checkout(int total)
    {
        // レジクラスが「現金払い」を直接作ってしまっている
        payment.Pay(total);
    }
}

このプログラムの問題点は、レジ（Cashier）が「現金（CashPayment）」のことしか知らない点にあります。時代の変化で「スマホ決済」や「クレジットカード」を追加したいと思っても、このレジクラスは一度壊して作り直す（コードを直接書き換える）必要が出てきます。

もし、これが大規模なシステムだったらどうでしょう？一つの変更が数百か所の修正を呼び、作業ミスによるバグが生まれる原因となります。だからこそ、「特定の相手に依存せず、誰とでも繋がれる仕組み」を作ることが、プロの設計において最も重要なのです。

3. 依存関係を減らす方法①：インターフェースを使う

インターフェースとは、「これだけの機能がありますよ」というルールだけを決めるものです。中身の実装は書きません。

たとえば、AクラスがBクラスに依存しているなら、Bの代わりに「IB（Bのインターフェース）」を使うことで、AはBの中身を知らなくても済みます。

これを実際のコードで見てみましょう。


public interface IMessageSender
{
    void Send(string message);
}

public class EmailSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine("メール送信：" + message);
    }
}

public class Notification
{
    private IMessageSender sender;

    public Notification(IMessageSender sender)
    {
        this.sender = sender;
    }

    public void Notify(string message)
    {
        sender.Send(message);
    }
}

このように、Notificationクラスは、EmailSenderクラスには依存していません。IMessageSender（インターフェース）に依存しています。

4. 依存関係を減らす方法②：コンストラクタインジェクション

コンストラクタインジェクションとは、クラスを作るときに、必要なものを外から「注入」する方法です。

上記のコードのように、NotificationクラスはIMessageSenderをコンストラクタで受け取っています。これが「依存の注入（Dependency Injection）」の一種です。

これにより、NotificationクラスはEmailSenderの具体的な情報を知らずに済みます。

5. 依存関係を減らす方法③：継承より委譲を使う

継承（けいしょう）とは、あるクラスが他のクラスを引き継ぐ仕組みですが、これは依存関係が強くなりがちです。

代わりに「委譲（いじょう）」という考え方を使うと、依存を弱くできます。委譲とは、「この処理は別のクラスに任せる」という方法です。

たとえば、車クラスがエンジンの処理を自分でやるのではなく、エンジンクラスに任せる、というようなイメージです。

6. 実行例

実際にNotificationクラスを使ってメッセージを送る例を見てみましょう。


class Program
{
    static void Main()
    {
        IMessageSender sender = new EmailSender();
        Notification notification = new Notification(sender);
        notification.Notify("こんにちは、世界！");
    }
}

このコードの実行結果は以下のようになります。


メール送信：こんにちは、世界！

7. クラス設計で意識すべきこと

初心者のうちは、クラスとクラスをつなげるのにnewをたくさん使ってしまいがちです。しかし、それではクラスが密接につながってしまい、後で変更しづらくなります。

以下の3つを意識するだけでも、設計はずっとよくなります。

newを減らす
インターフェースを使う
処理を他のクラスに任せる（委譲）

これらを意識して、なるべく「部品を組み合わせて作る」ような考え方を持つとよいでしょう。

まとめ

ここまで、C#のクラス間の依存関係をできるだけ減らし、保守性や再利用性、拡張性を高めるための設計ポイントを丁寧に見てきました。依存関係を適切に整理することは、初心者の段階から意識しておくと後の開発がぐっと楽になります。とくに、複雑なプロジェクトや長期的に運用されるアプリケーションでは、依存の整理ができているかどうかで開発速度や品質が大きく変わります。まず最初に、依存関係とは何かを理解することが大切でした。クラスが直接ほかのクラスに結びついてしまうと、どちらか一方を変更しただけで予期せぬ影響が広がるという課題がありました。そこで、インターフェースを使った抽象化が役に立ちます。実装の中身を気にせずに、必要なメソッドだけを約束として扱えるため、クラス同士の結びつきを弱められます。また、インターフェースと相性が良いのがコンストラクタインジェクションでした。必要な依存を外部から渡すことで、クラス側が自分で依存先を決めなくてよい構造になります。この考え方は、アプリケーション全体を柔軟にし、テストがしやすくなるという重要な効果があります。テストのためにモックを渡せることは、実務でもよく求められるポイントです。さらに、継承より委譲を採り入れる発想も重要です。継承は便利ですが、強い依存を生み出しがちなため、適度な距離感を保つために委譲を使うほうが望ましい場面は多くあります。クラスの責任を分担し、役割を明確に切り分けることで、アプリケーションの構造はすっきりと整っていきます。依存関係を適切に管理するという考え方は、C#だけでなくオブジェクト指向言語全体に応用できます。とくにC#ではインターフェースが豊富で、DI（依存性注入）の仕組みを扱うフレームワーク（ASP.NET Coreなど）も充実しているため、初心者の段階からこうした設計の基礎を意識しておくと大きな武器になります。実行例で示したコードのように、実際に触りながら依存がどのように減らせるのかを体験すると、抽象化の大切さがさらに理解しやすくなるでしょう。メッセージ送信のようなシンプルな例でも、インターフェースを介した構造のほうが変更に強く、ほかの実装を追加する場合も効率的に拡張できます。以下に、依存関係を整理するためのサンプルコードをもう一度振り返りとして示します。応用として、複数の実装を切り替えるケースにも対応できる形にしています。

依存関係を整理するサンプルコード


public interface ILoggerService
{
    void Log(string message);
}

public class FileLogger : ILoggerService
{
    public void Log(string message)
    {
        Console.WriteLine("ファイル出力：" + message);
    }
}

public class DatabaseLogger : ILoggerService
{
    public void Log(string message)
    {
        Console.WriteLine("データベース保存：" + message);
    }
}

public class LogProcessor
{
    private readonly ILoggerService logger;

    public LogProcessor(ILoggerService logger)
    {
        this.logger = logger;
    }

    public void Process(string message)
    {
        logger.Log(message);
    }
}

このように、インターフェースを使って実装をゆるく結びつけることで、どの実装を使っても同じメソッドで処理を実行できます。依存関係を弱める設計は柔軟で拡張しやすく、プロジェクトの規模が大きくなるほど効果が大きくなります。これらの考え方を身につけておくと、C#のクラス設計が格段にわかりやすくなり、複数の機能を連携させる際にも迷わず取り組めるようになります。

先生と生徒の振り返り会話

生徒

「今日の学習で、依存関係を弱めることがこんなに大事だとは思いませんでした。特にインターフェースの役割がすごくわかりやすかったです。」

先生

「良い気づきですね。インターフェースはクラス同士の結びつきをゆるくして、コードをより扱いやすくしてくれます。実務でも頻繁に使われる基本的な仕組みです。」

生徒

「コンストラクタインジェクションも理解できました。外から依存を渡すだけで、こんなに柔軟になるんですね。」

先生

「その通りです。テストしやすくなるという利点も大きいので、ぜひ積極的に使っていきましょう。」

生徒

「継承より委譲を使うという発想も、新しい視点でした。どんどん応用できそうです。」

先生