ざきの学習帳（旧 zackey推し ）

日々の学びを書きます

Clean Architecture 第11章「DIP: 依存関係逆転の原則」の読書メモ

クリーンアーキテクチャ 感想 プログラミング 設計

現在、自分がいるコミュニティにて、クリーンアーキテクチャの輪読会が行われています。

自分が第10章〜第11章となり、以下についての資料をまとめました。

この記事では、第11章「DIP: 依存関係逆転の原則」の理解を深めるために、
ブログ等の文献を読み漁り、咀嚼した内容をメモしておきたいと思います。

咀嚼した内容

以下のリポジトリ→ディレクトリ内でお試しコードを打ちながら咀嚼しました。

github.com

序章

  • DIPが伝えたいこと
    • 具象ではなく抽象だけを参照しているもの
  • 柔軟なシステム＝抽象を参照しているもの
    • 柔軟ではないシステム＝具象を参照しているもの
  • 具象（モジュール）の定義
    • 本では、関数が実装されているものを指す
  • 適応範囲
    • すべてに適応するのは現実的ではない
      • String等、OSやプラットフォーム周りについては許容してもOK
    • 適応範囲は、システム内の変化しやすい具象要素
      • 今現在開発しているモジュール
      • 変更が入るモジュール

安定した抽象

  • 優れたソフトウェア設計者は...
  • コーディングレベルでの説明
    • 変化しやすい具象クラスを参照しない
      • 抽象インタフェースを参照する
        • 言語関係なし
      • AbstractFactoryパターンを用いるとよい
        • というか、それしかないらしい
    • 変化しやすい具象クラスを継承しない
      • 静的型付言語の継承は協力かつ幻覚なもののため、十分に注意すること
        • おそらく、意図しない動きをさせる危険性があるためと思われる
    • 具象関数をオーバーライドしない
      • オーバーライドしたい場合は、元の関数を抽象関数にして、パターン毎の実装をすべき
    • 変化しやすい具象を名指しで参照しない
      • DIPの言い換え

Factory

安定した抽象に従うと、具象オブジェクトを生成する際に特別な処理が必要。

事実上、すべての言語において、オブジェクトの具象定義を含むソースコードの依存は避けられない。

そのため、大半のオブジェクト指向言語ではAbstractFactoryを用いて、依存性を管理する。

Abstract Factoryについて

まとめ

咀嚼した結果、

  • Abstract FactoryのcreateFactoryあたりは、もっとスマート（依存しないような形）で実装できたら良さそう
    • Railsのconstantizeのように、文字列からクラス名を生成する仕組みがあると便利かも
  • DIPは原則（規則）、DIやAbstract Factoryはそれに準拠するための手法

のようなイメージでインプットしました。

もし、気になる点等ありましたら、FBいただけると助かります。🙇‍♂️