Larvalの仕組みであるファサード（オブジェクト注入、サービスコンテナ、サービスプロバイダー）について

まずはこちらをご覧いただきたい。

Messengerクラスのreturnで使っているsendメソッドは、

SenderInterfaceインターフェイスを継承しているMailSenderクラスとBikeSenderクラスのsendメソッドだと思いますが、
MailSenderクラスとBikeSenderクラスのsendメソッドをmailtransmissionというメソッドに修正した場合、
Messengerクラスのreturnで使っている箇所も、
return $this->sender->mailtransmission($message);に修正しないといけませんよね。

まず、依存性注入やDIコンテナを導入する観点として保守性や柔軟性の向上という点が思想とされていますが、参照URL先の依存性の注入を使っていないケースと依存性の注入を使っているケースの話では柔軟性についてはとてもわかります。

そもそも依存性の注入を使っていないケースで
BikeSenderクラスはデッドロジックになってますよね。。。
あえて、わかりやすくするためにそうしてるのかもですが。

そこは置いといて話は戻り、依存性注入の話とはズレますが
MailSenderクラスとBikeSenderクラスのメソッド名を修正したら
Messengerクラスで、MailSenderクラスとBikeSenderクラスの使用するメソッド名も修正しないといけない点は、柔軟性とはいえないと思います。

そもそも、参照URL先の内容に対する私の観点が違うのでしょうか？
一応、参照URL先の内容はファサードまで読みました。
最終的にファサードを使うと何が嬉しいのかというところで、柔軟性が上がった結果、メモリー効率やパフォーマンス効率がよくなるという理解はあるのですが、もう一度、依存性の注入から見返していくと、そもそもMessengerクラスが、MailSenderクラスに依存しているから柔軟性がないっていうけど、依存性の注入を使ったケースでもメソッド名修正したらその箇所修正しなきゃいけないから、その点柔軟ではないよね。って思ってるのですが、結局、依存性の注入という概念でも最小限の修正は必要なのでしょうか？

何が知りたいとかではなく、ただ思ったことを質問してみました。

m.ts10806

2017/06/05 02:22

色々と質問立てられていますが、こちらは解決したのでしょうか？

m.ts10806

2018/02/09 00:16

https://teratail.com/help/question-tips#questionTips4-2

行動規範の内容に同意します

回答2件

ベストアンサー

質問内容対する私の理解に誤解があったらごめんなさい。

MailSenderクラスとBikeSenderクラスのメソッド名を修正したらMessengerクラスで、MailSenderクラスとBikeSenderクラスの使用するメソッド名も修正しないといけない点は、柔軟性とはいえない

が意味する所は、例えば…

PHP
1class MailSender implements SenderInterface {
2    public function send($message) {
3        // ここで、メールでメッセージを送る
4        return "メールで送りました。";
5    }
6}

におけるクラスのメソッド名が下記の様にsendからMessageSendに変わったとすると、

PHP
1class MailSender implements SenderInterface {
2    public function MessageSend($message) {
3        // ここで、メールでメッセージを送る
4        return "メールで送りました。";
5    }
6}

利用する側が

PHP
1echo $messenger->send("合格通知") . "\n";

ではなく、

PHP
1echo $messenger->MessageSend("合格通知") . "\n";

としなければいけない事を指して、「柔軟性が無い」と仰っているのでしょうか？
(Interfaceも修正しなければいけないのですが…)

これは、流石にどうしようも無いと思います…何を呼んだら良いのか分からなくなりますからね。
(でも、IDEのリファクタリングとかで一括で変更できるかもしれません)

私は参照先HPの筆者ではないので正確なことは言えませんが、「柔軟性」といっているのは下記の部分ではないかと理解しました。

DIコンテナを導入したことで、MessengerクラスとSenderInterfaceを持つクラスの生成を１箇所に集約することができました。また、MailSenderやBikeSenderクラスが他のクラスに依存するなどして、構造に変更があった場合でも、DIコンテナへのバインド部分（Config部分）だけを修正すればよくなります。Main部分において、どのようにクラスをnewするかといったクラス構造は隠蔽されます。

というわけで、