はじめに

筆者はSIerでエンジニアをしております。やりたいことよりも、案件をベースに、その案件に合わせた技術スタックを修得しています。

今回は、やっと腰を据えてSpringBootを扱いました。あらためてDIのありがたさについて学んだことを記載します。

目次

なんとなく使っているDIのありがたさを理解する

前提

以下の技術スタックを用います。

java(たぶんバージョンに影響しない概念です。)
SpringBoot(たぶんバージョンに影響しない概念です。)

DIとは

Dependency Injection。直訳で依存性の注入。クラスAからクラスBに直接依存するのではなく、外側から実体への依存を注入できるようにする技術。こんなこと言ってもわからないので、実例と、使わない時の問題、使ったら嬉しくなることを見ていきましょう。

DIについて理解を深める

前提

mainからクラスAを呼び出し、クラスAの中ではクラスBを使用します。

DIを使わない場合

愚直に実装するといかのようになります。まあ、悪くはないですね。

// Main.java
public class Main {
    public static void main(String[] args) {
        ClassA classA = new ClassA();
        classA.doSomething();
    }
}

// ClassA.java
public class ClassA {
    private ClassB classB;

    public ClassA() {
        // クラスAの中で直接ClassBのインスタンスを生成している
        this.classB = new ClassB();
    }

    public void doSomething() {
        // ClassBの処理を呼び出す
        String result = classB.process();
        System.out.println("ClassA: " + result);
    }
}

// ClassB.java
public class ClassB {
    public String process() {
        return "Processing in ClassB";
    }
}

一見、「いいんじゃね」と思うのですが、以下のような問題があります。

クラスBが外部APIなどを呼び出している場合にテストが困難
クラスBのインタフェースが変更される場合に、クラスAの変更も必要になる

実装としては間違ってはいないのですが、拡張性や保守性に問題が生じる可能性があります。

ということで、これをDIを実装してみましょう。

DIを使う場合

以下のように、クラスAを生成する際に、クラスBも生成して注入します。これが、Aからみると、上位から「注入」されていることになります。

// ProcessorB.java (インターフェース)
public interface ProcessorB {
    String process();
}

// ClassB.java (実装クラス)
public class ClassB implements ProcessorB {
    @Override
    public String process() {
        return "Processing in ClassB";
    }
}

// ClassA.java
public class ClassA {
    private final ProcessorB processor;  // インターフェースを使用

    // コンストラクタインジェクション
    public ClassA(ProcessorB processor) {
        this.processor = processor;
    }

    public void doSomething() {
        String result = processor.process();
        System.out.println("ClassA: " + result);
    }
}

// Main.java
public class Main {
    public static void main(String[] args) {
        ProcessorB processor = new ClassB();
        ClassA classA = new ClassA(processor);  // 依存性を外部から注入
        classA.doSomething();
    }
}

で、、、、なにが嬉しいのか。それは以下のようなパターンで、DIの恩恵が受けられます。

テストがしやすくなる
新機能追加時の変更が最小限で済む
クラスBはインタフェースに従った実装をする

テストがしやすくなる例

テスト時には、外部APIを呼び出さないモック実装を注入できます。

// テスト用のモック実装
public class MockClassB implements ProcessorB {
    @Override
    public String process() {
        return "テスト用の固定値";
    }
}

// テストコード
public class ClassATest {
    @Test
    public void testDoSomething() {
        // テスト用のモックを注入
        ProcessorB mockProcessor = new MockClassB();
        ClassA classA = new ClassA(mockProcessor);
        
        // テストの実行
        classA.doSomething();  // -> "ClassA: テスト用の固定値" と出力される
    }
}

新機能追加時の変更が最小限で済む例

ログ出力機能を追加したい場合でも、既存コードを変更せずに対応できます。

// ログ出力機能を追加した実装
public class LoggingClassB implements ProcessorB {
    private final ProcessorB original;
    
    public LoggingClassB(ProcessorB original) {
        this.original = original;
    }
    
    @Override
    public String process() {
        System.out.println("処理開始");
        String result = original.process();
        System.out.println("処理終了");
        return result;
    }
}

// 使用例
public class Main {
    public static void main(String[] args) {
        ProcessorB original = new ClassB();
        ProcessorB withLogging = new LoggingClassB(original);
        
        ClassA classA = new ClassA(withLogging);
        classA.doSomething();
    }
}

ちょっとだけでも、DIの嬉しさが伝わりましたでしょうか。
でも、、、単純な例だと嬉しいのですが、クラスの階層はもっと深いですよね。実際にはこんなことになります。

実際はそんなに甘くない例

例えば、以下のような3階層の依存関係があるとします。

ClassA → ServiceB → RepositoryC
そうすると、以下のように全部の依存関係の構築が必要になります。

// Main.java
public class Main {
    public static void main(String[] args) {
        // すべての依存関係を手動で構築する必要がある
        RepositoryC repositoryC = new RepositoryC();
        ServiceB serviceB = new ServiceB(repositoryC);
        ClassA classA = new ClassA(serviceB);
        
        classA.doSomething("データ");
    }
}

// ClassA.java
public class ClassA {
    private final ServiceB serviceB;

    public ClassA(ServiceB serviceB) {
        this.serviceB = serviceB;
    }

    public void doSomething(String data) {
        String result = serviceB.process(data);
        System.out.println("ClassA: " + result);
    }
}

// ServiceB.java
public class ServiceB {
    private final RepositoryC repositoryC;

    public ServiceB(RepositoryC repositoryC) {
        this.repositoryC = repositoryC;
    }

    public String process(String data) {
        // データを加工してから保存
        String processed = data + "_processed";
        return repositoryC.save(processed);
    }
}

// RepositoryC.java
public class RepositoryC {
    public String save(String data) {
        // 実際にはDBに保存する処理
        return "Saved: " + data;
    }
}

うーん、めんどくさいですね。

ここで、DIコンテナですよ

これまでは手作業でDIを実装してきました。階層がう深くなると手作業で管理は効率悪いですね。それも仕組みに任せましょう。ここではSpringBootのDIコンテナ使用して、ありがたみを感じましょう。

同じ構成をSpringBootで実装すると、以下のようになります。DataControllerというAPIを実装することとします。

// ClassA.java
@Component  // コンポーネントとして登録
public class ClassA {
    private final ServiceB serviceB;

    @Autowired  // DIコンテナによる依存性の注入
    public ClassA(ServiceB serviceB) {
        this.serviceB = serviceB;
    }

    public void doSomething(String data) {
        String result = serviceB.process(data);
        System.out.println("ClassA: " + result);
    }
}

// ServiceB.java
@Service  // サービスとして登録
public class ServiceB {
    private final RepositoryC repositoryC;

    @Autowired  // DIコンテナによる依存性の注入
    public ServiceB(RepositoryC repositoryC) {
        this.repositoryC = repositoryC;
    }

    public String process(String data) {
        String processed = data + "_processed";
        return repositoryC.save(processed);
    }
}

// RepositoryC.java
@Repository  // リポジトリとして登録
public class RepositoryC {
    public String save(String data) {
        return "Saved: " + data;
    }
}

// Controller層を追加
@RestController
@RequestMapping("/api")
public class DataController {
    private final ClassA classA;

    @Autowired
    public DataController(ClassA classA) {
        this.classA = classA;
    }

    @PostMapping("/process")
    public ResponseEntity<String> processData(@RequestBody DataRequest request) {
        String result = classA.doSomething(request.getData());
        return ResponseEntity.ok(result);
    }
}

さて、何か簡素になりました。それぞれのクラスにアノテーションがつきましたが、コンストラクタの引数でのやり取りは減りました。

SpringBootの環境下で、ルールに従ってアノテーションを付与することによって、DIコンテナが使用できて、

自動で依存を解決
手動での注入が不要
など、手動DI以上の恩恵が受けられます。

これでクラス間の依存関係を管理をSpringBootにお任せすることができます。

まとめ

DIを使わないコードでも、動作はします。でも、テストのしづらさや、機能追加時の改修範囲の広がりなど、いくつかの問題が出てきます。

そこでDIを使うと

テストが楽になる（モック実装を注入できる）
新機能追加が楽になる（既存コードの変更が最小限で済む）

ただし、手動でDIを実装すると、クラスの階層が深くなるにつれて大変になってきます。たとえば3階層の依存関係だと、すべての依存関係を手動で構築する必要があって、なかなかめんどくさい。

そこで、SpringBootなどのDIコンテナです。アノテーションを付けるだけで

自動で依存関係を解決してくれる
インスタンス生成の順番とかを気にしなくて良くなる

なんとなく使っていたDIですが、ちょっとだけでもそのありがたさが伝わりましたでしょうか。

生のJavaからSpringBootにステップアップしたら避けては通れない概念です。
最初？の壁になりそうなDIの概念について、少しでも理解が進めば嬉しいです。