タイトル
フレームワークを作りながらLaravelのアーキテクチャを学ぶ
GMOペパボ endu さん
なぜフレームワークを作るのか
フレームワークの動きを学びたかった。
Phper人生
手段は本質よりも早く廃れる。
→ だから根っこの部分を知りたかった。
→ それが本質に当たる、ララベルのアーキテクチャがなぜそのアーキテクチャを採用したのかといったことを知りたかった。
Soku Framework
ClassLoaderがなぜあるのか？
composer.loaderを自作したみたいなもん。
基本に忠実なMVCを作っている。
→ 名前解決が重要だと実感できる。
→ オレオレFWの簡単なテストを書くと良さげ！(これ研修にいかせそうだな)
Laravelとオレオレフレームワークを比較
DI
「依存性の注入」
言葉わかりにくくね？
「コンストラクタインジェクション」
ServeiceINterfaceクラスを作成し、そこからコンストラクタインジェクションを行う。
結論
必要なオブジェクトを外部から注入する
DIコンテナ
注入する内容が多くなると面倒。醜い。
インスタンスのDIコンテナをやると、使うときに、インスタンスの生成を1行か2行に短縮できる。
事前にオブジェクトの生成をやる。
サービスコンテナ
Laravelが提供しているのが、サービスコンテナ
bind → インスタンスの生成方法を登録する。
resolve → サービスコンテナにおいてインスタンスを取得する
ファサード
- ファサードクラス(config)の解決
- ファサードクラスのクラスメソッド実行
- サービスコンテナからインスタンスを取得
- インスタンスメソッドの実行
本題: Laravel
アーキテクチャあんまり変わってなくね？
→ 違うんですよ。
アーキテクチャの各機能が密結合だったんだが、
ファサードを使うと、全て単体になり、ファサードを使ってそれぞれの依存関係を疎にしてくれている。
ファサード本当にいいのか？
便利ではあるが、依存関係が隠蔽されるので、使うすぎるとわかりづらくなってしまう。
クラス中心の責任が不明瞭になってしまう。
質問
何を伝えたかったのか
ファサードってどこからも呼べるので、目的に沿って必要な時のみ適切に使いましょうということ！
DIコンテナのライブラリとかティンプル以外にもサンプルにしたものあるのか？
ティンプルしか使っていない。
そのあとにLaravelのものと見比べた。