Zenn
📑

Head First デザインパターン 第2版 まとめ

2024/10/16に公開
Go
デザインパターン
idea

パターンとその使い方を説明されても、今一つ頭に入ってこなかった。
本書では、具体的なケースとその設計に至る考えた方がある程度示されているため、本書での学び直しを行うことにした。

また、Go言語の自習のためGo言語で実装例を記述していく。が、Go言語がオブジェクト指向言語ではなく、自分のGo言語への理解もそれほど深くないため、よりより実装方法があるのかもしれない。

注意

  • 本書は、あくまでもオブジェクト指向言語でデザインパターンを習得するための書籍
  • 関数がファーストクラスの値であるような言語では、同じパターンを関数だけで(場合によってはよりシンプルに)解決できる場合がある
  • つまり、実際の利用にあたっては、オブジェクトを使うパターンだけでなく、関数を使ってよりシンプルに実現できるかどうかも検討してみた方がよい

目次

設計原則まとめ

設計原則

  • アプリケーション内の変化する部分を特定し、不変な部分と分離する
    • 変化する部分を取り出して「カプセル化」する
    • そうすることで、コードの他の部分に影響を与えなくなる
    • その結果、コード変更による予期せぬ結果が少なくなり、システムの柔軟性が向上する

設計原則

  • 実装に対してでなく、インターフェースに対してプログラミングする
    • Duckの振る舞いは別クラスに配置する
    • この方法を取ることで、Duckのサブクラスは振る舞いの実装の詳細を知る必要がない
  • 「インターフェースに対するプログラミング」とは、実際は「スーパータイプに対するプログラミング」を意味する
    • 宣言する変数の型をスーパータイプ(通常は抽象クラスかインターフェース)にして、変数に代入されるオブジェクトがスーパータイプの任意の具象実装となるようにすべき
    • 変数を宣言するクラスは、実際のオブジェクトの型について知る必要がなくなる

設計原則

  • 相互にやり取りを行うオブジェクトの間には、疎結合設計を使う
    • 疎結合設計はオブジェクト間の相互依存を最小限にするため、変更に対応できる柔軟なOOシステムを構築できる

設計原則(open-closedの原則)

  • open-closedの原則
    • クラスを拡張に対しては開かれた状態にするべきだが、変更に対して閉じた状態にする
    • 既存コードは変更せずに、クラスを簡単に拡張して新しい振る舞いを組み込めるようにする

設計原則(依存関係反転の原則)

  • 抽象に依存する
  • 具象クラスに依存指定はいけない

この原則は、「実装に対してではなくインターフェースに対してプログラミングする」という原則に似ている。しかし、この依存関係反転の原則の方が抽象化についてされに強く主張している。

  • 高水準のコンポーネントは低水準のコンポーネントに依存すべきではない
  • どちらも抽象に依存すべき

Discussion