はじめに
Laravel はアーキテクチャの自由度が高い点でユニークなフレームワークに思う。
しかしチームで開発する上では、実装者によって書き方やアーキテクチャが変わりやすい点もある。
加えて MVC アーキテクチャだけではモデルやコントローラが太りやすい。
そんななか弊社で「DIに基づいた設計を行う」「ファーサードの使用は違法」とする「設計勧告案」が登場した。
でもあまり順守されていないように思うので、私の理解を書く。
なぜ DI か
ファサードは簡単に使える。
自分で取り込んだり、設定したりする必要があり、長くて覚えにくいクラス名を使わずに、Laravelの機能を簡素で覚えやすい文法で使ってもらえます。その上に、PHPの動的メソッドのユニークな使用方法のおかげで、簡単にテストができます。
https://readouble.com/laravel/6.x/ja/facades.html#when-to-use-facades
DI なら同じテスタビリティで、
クラスの依存関係を明示して、「大きなコンストラクタの視覚的なフィードバック」を得られる。
ファサードの一番の危険性は、クラスの責任範囲の暴走です。ファサードはとても簡単に使用でき依存注入も必要ないため、簡単にクラスが成長し続ける結果、一つのクラスで多くのファサードが使われます。依存注入を使用すればクラスが大きくなりすぎることに伴う、大きなコンストラクタの視覚的なフィードバックにより、この危険性は抑制されます。
https://readouble.com/laravel/6.x/ja/facades.html#facades-vs-dependency-injection
依存関係が増えてコンストラクタが大きくなったら、クラスをわけるサイン。
またはコンストラクタに小さく収まる単位にクラスの責任範囲をわけるとも言える。
ヘルパは？
ヘルパもファサードと同じ利点・欠点を持ち、同様に禁止されると考える。
どう使うか
ファサードとクラスなら公式に対応表があります。
Carbon
Illuminate\Support\DateFactory が使えます。
Carbon\Carbon, Carbon\CarbonImmutable と異なり、デフォルトの実装を順守してどちらかを返します。
ヘルパ
ソースコードを見て必要なクラスを探す。
https://github.com/laravel/framework/blob/6.x/src/Illuminate/Support/helpers.php
https://github.com/laravel/framework/blob/6.x/src/Illuminate/Foundation/helpers.php
わかりづらいのであとで対応表を書くかもしれない。
対応表を書きました。
Laravel 6.x ヘルパ DI クラス一覧 - Qiita
おわりに
DI を使うことでクラスの依存関係を明示し、適度な責任範囲を保てる。
統一的に使われれば、ビジネスロジックを集約でき、よりメンテナンスしやすくなると思われる。