C#におけるデザインパターンの現状とシングルトンパターンの再考

2025年3月22日

本資料では、C#での開発において、近年使わない方が良いとされるデザインパターンとしてシングルトンパターンについて検証します。依存性注入（DI）コンテナの普及に伴い、シングルトンパターンの使用が再考される背景とその理由、そして代替となるアプローチについてまとめています。

UnityにおけるVContainerを利用したDIコンテナ実装ガイド

本資料では、Unityの開発において従来のシングルトンパターンの課題と、代替としての依存性注入（DI） ...

https://soft-rime.com/post-22618/

1. 1. 背景
2. 2. シングルトンパターンの課題
3. 3. 依存性注入（DI）コンテナの利点
4. 4. 適用例と考慮事項
5. 5. コード例
- 5.1. 5.1 シングルトンパターンの例
- 5.2. 5.2 依存性注入（DI）コンテナを利用した例
6. 6. 結論

1. 背景

デザインパターンの役割:
デザインパターンは、ソフトウェア開発における共通の問題を解決するための再利用可能な解決策です。C#をはじめとする多くのプログラミング言語で活用されています。
シングルトンパターンの伝統的な位置づけ:
シングルトンパターンは、クラスのインスタンスを1つだけに制限し、グローバルなアクセス手段を提供するためのパターンとして広く使われてきました。

2. シングルトンパターンの課題

グローバルな状態管理:
シングルトンはアプリケーション全体で共有される状態を持つため、予期せぬ副作用やバグの原因となりやすいです。
テストの難易度:
シングルトンのグローバル性は、ユニットテストやモックの導入を困難にし、テスト環境での依存関係の管理を複雑にします。
保守性の低下:
状態管理が一箇所に集中するため、コードの変更や拡張が困難になり、将来的な保守性に悪影響を及ぼす可能性があります。

3. 依存性注入（DI）コンテナの利点

ライフサイクル管理:
DIコンテナを用いることで、インスタンスの生成や破棄を柔軟に管理でき、シングルトンと同等の効果を必要な場合に限定して適用することが可能です。
疎結合な設計:
DIを活用することで、クラス間の依存関係を明示的に定義でき、コードの再利用性やテストの容易さが向上します。
テスト容易性の向上:
DIコンテナにより依存関係を注入することで、モックやスタブを用いたテストが行いやすくなり、単体テストの実施がスムーズになります。

4. 適用例と考慮事項

シングルトンパターンの適用が適切なケース:
グローバルに一つだけのインスタンスが必要で、そのライフサイクルを厳密に制御する必要がある場合には、シングルトンパターンが有効です。
DIコンテナへの移行の推奨:
多くのモダンなアプリケーションでは、DIコンテナを使用することで、シングルトンパターンに依存せずに柔軟な設計が実現されています。これにより、コードの可読性や保守性、テスト容易性が向上します。
状況に応じた選択の重要性:
シングルトンパターンを全て排除するのではなく、アプリケーションの要件や設計方針に応じて、シングルトンとDIコンテナのそれぞれの利点・欠点を考慮することが重要です。

5. コード例

5.1 シングルトンパターンの例

以下は、従来のシングルトンパターンの実装例です。シングルトンパターンは、クラスのインスタンスが1つだけ生成されることを保証します。

public class Singleton
{
    private static Singleton _instance;
    private static readonly object _lock = new object();

    // コンストラクタは外部からアクセスできない
    private Singleton() { }

    public static Singleton Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lock)
                {
                    if (_instance == null)
                    {
                        _instance = new Singleton();
                    }
                }
            }
            return _instance;
        }
    }

    public void DoSomething()
    {
        Console.WriteLine("Singletonが動作しています。");
    }
}

利用例:

class Program
{
    static void Main(string[] args)
    {
        Singleton.Instance.DoSomething();
    }
}

5.2 依存性注入（DI）コンテナを利用した例

以下は、Microsoft.Extensions.DependencyInjectionを利用してDIコンテナでサービスのライフサイクルを管理する例です。DIコンテナを使うと、必要に応じてシングルトンやトランジェント、スコープドなどのライフサイクルを柔軟に設定できます。

using Microsoft.Extensions.DependencyInjection;

public interface IMyService
{
    void DoSomething();
}

public class MyService : IMyService
{
    public void DoSomething()
    {
        Console.WriteLine("DIコンテナを利用したサービスが動作しています。");
    }
}

class Program
{
    static void Main(string[] args)
    {
        // DIコンテナの設定
        var serviceCollection = new ServiceCollection();
        // 必要に応じて AddSingleton, AddTransient, AddScoped を選択可能
        serviceCollection.AddSingleton<IMyService, MyService>();

        var serviceProvider = serviceCollection.BuildServiceProvider();

        // DIコンテナからサービスを取得して利用
        var myService = serviceProvider.GetService<IMyService>();
        myService.DoSomething();
    }
}

6. 結論

C#においては、依存性注入（DI）コンテナの普及により、従来のシングルトンパターンの利用は慎重に検討されるべき状況となっています。シングルトンパターンはグローバルな状態管理を引き起こし、テストや保守性に課題を生む可能性があるため、可能な限りDIコンテナを活用した設計への移行が推奨されます。ただし、すべてのケースでシングルトンが不要というわけではなく、適切なシナリオにおいては有効なパターンとなり得るため、状況に応じた柔軟な選択が求められます。

以上の点を踏まえ、開発の現場ではシングルトンパターンとDIコンテナの特性を理解し、より適切なアプローチを選択することが重要です。

C#,DI（依存性注入）,デザインパターン

Posted by hidepon