簡単に言うと、依存関係はインターフェイスや抽象クラスに対して設定すべきものであり、それを実装したクラスに対して設定してはいけないってこと。先ほどの例をこの原則に沿って書き直すと、こんなふうになる。クラスは、具象クラスではなくインターフェイスに依存するように変わった。何がうれしいんだろう。こんな場面を考えてみよう。君は今、とあるチームの一員として作業をしている。アダプターを作っているのは別のメンバーだ。最初の例だと、その人がアダプターを完成させるまでは、自分のコードのユニットテストのモックを作れない。インターフェイスに依存するようにした新しいバージョンだと、そのインターフェイスを使ってモックを作ることができる。同僚が作るアダプターもそのインターフェイスに沿っているとわかっているからだ。そんなことより、もっとすばらしいメリットもある。こっちの方式のほうが、コードがずっとスケーラブルになるんだ。仮に将来、別のデータベースに移行することになったとしよう。そんな場合でも、このインターフェイスを実装した新しいアダプターを書いたらそれでおしまいだ。それ以外は何もいじる必要がない。新しいアダプターがきちんと決まりごとに従っているということを、インターフェイスが保証してくれるからだ。コンテナDIコンテナについてまず知っておくべきなのは、DIコンテナを使ってさえいれば「依存性の注入」ができるわけではないってことだ。DIコンテナは、依存性の注入を実現するための便利な道具として使える。使い方をミスって、サービスロケーションというアンチパターンを作ってしまっていることも多い。依存関係を別の場所に移そうとしていたはずなのに、よりきつい依存関係を作り込むことになる。おまけにそのコードはわかりにくくなってしまうし、テストもしづらくなる。いまどきのフレームワークにはたいていDIコンテナが用意されていて、依存関係をコード以外のところで設定できる。要するに、アプリケーションのコードがすっきりと書けて、フレームワーク本体とあまり密接につながりすぎないようにできるということ。コードを書いていると、情報を保存するためにデータベースを使うことが多くなる。データベースを操作するには、いくつかの方法がある。ネイティブドライバを使うことだった。このデータベースしか使わないよ!っていうのならネイティブドライバもいい。つなぐことがあるとか、そんな場合は同じドライバでは対応できない。覚えないといけないことになる。拡張モジュールは既に思いっきり古くなっていて、これらの拡張モジュールがその後継になっている。5.5.0で「廃止予定」となった。7.0.0で公式に削除された。設定を調べるまでもない。モジュールを使ってるってことだ。使うつもりがないのだとしても、今ちゃんと考えておかないと、いざというときに大変なことになる。徐々に置き換えていくことだ。すれば、後になってあせらずにすむ。置換すればOK」などと書いているような記事には用心すること。利点(パラメータのバインドなど。用意されている)の活用ができなくなってしまう。データベースとの接続を抽象化するライブラリだ。いろんなデータベースを同じインターフェイスで扱える。MySQLを使うコードもSQLiteを使うコードも、基本的には同じようになるってことだ。存在しない機能をエミュレートするものでもない。接続するためのものだ。クエリに埋め込めるということだ。インジェクション攻撃を心配しなくてもよくなる。ステートメントとバインド変数を使えばよい。スクリプトを考えてみよう。使って、データベースからユーザー情報を取り出す。ダメ、ゼッタイ!こんな恐ろしいコードを書いちゃいけない。直に埋め込んでいることになる。