「@Autowired」に、DIの歴史とエモさを感じたわ

自分が過去にSpring Bootの勉強をしていた時に書いていたソースを振り返ってみると「おや…？」と思う瞬間がありました。

見つけたのは、大量のフィールドインジェクション。

クラスの変数に直接 @Autowired がペタペタ貼ってある、あの光景です。

「あぁ、このソースコードを書いていた頃は、きっとあの頃だったんだな…」と、コードから時代背景が透けて見えるような感覚。これ、エンジニアあるあるですかね？

でも、最近のSpringの流儀だと「フィールドインジェクションは推奨されにくい」なんて言われがち。せっかくなので、DI（依存性注入）の推奨スタイルがどう変わってきたのか、自分の整理がてら歴史を掘り起こしてみました。

① XML時代（設定ファイル時代）

昔は applicationContext.xml という巨大な地図に、「このクラスとこのクラスをガッチャンコしてね」と全部書いていました。（わかる？）

<bean id="myService" class="com.example.MyServiceImpl">    
    <property name="myRepository" ref="myRepository" />
</bean>

こんな具合です。Beanが増えるたびにXMLが数千行になり、管理するだけで日が暮れる。まさに修行の時代でした。

② フィールド注入時代（アノテーション革命）

そこで登場したのが @Autowired。

「フィールドにアノテーションを貼るだけ！？XMLいらないだと？！」と驚きの声が多かったとか。当時の私は「アノテーションってなんだろ？」というレベル感でした。

@Service
public class MyService {
    @Autowired  // ← これを貼るだけでOK！当時は魔法に見えた
    private RepositoryA repositoryA;
    
    @Autowired
    private RepositoryB repositoryB;
}

これがあるあるのフィールドインジェクション。今でもひと昔前のプロジェクトでよく見かけるのは、この時代の爆発的な流行の名残ですね。

③ コンストラクタ注入時代（現代）

ところが、フィールド注入には「テストがしにくい」「final（不変）にできない」という弱点がありました。JunitのテストコードにMockitoの設定が大変なことに。。。そこで「やっぱりコンストラクタで渡すのが一番硬くて安全だよね」という原点回帰が起こったようです。

@Service
public class MyService {
    private final RepositoryA repositoryA;
    private final RepositoryB repositoryB;

    // Spring 4.3からは、コンストラクタが1つなら @Autowired さえ不要に
    public MyService(RepositoryA repositoryA, RepositoryB repositoryB) {
        this.repositoryA = repositoryA;
        this.repositoryB = repositoryB;
    }
}

こんな具合です。「書かなくていい（自動で判断してくれる）のが、一番の進化」という境地に達したようです。

④もっと書かなくていい時代

今回いろいろ調べてて、「これ、めっちゃ素敵やん」と個人的に感動したのがLombokの @RequiredArgsConstructor です。

コンストラクタ注入が安全なのは理解した。。でも、正直「コンストラクタを書くのも、面倒だなー。。。」ってずっと思ってたんですよ。

それが、これですよ。

@Service
@RequiredArgsConstructor // ← これでおしまい。コンストラクタを自動生成してくれる
public class MyService {
    private final RepositoryA repositoryA; // finalをつけるだけでDI対象になる
    private final RepositoryB repositoryB;
}