ヨタの日々

_ Head Firstオブジェクト指向分析設計 を読みました

原著 Head First Object-Oriented Analysis and Design

サンプルコードは原著から辿る https://resources.oreilly.com/examples/9780596008673/

1章

1. まず顧客の要件を満たすものを作る
2. オブジェクト指向の基本原則を適用し、変更容易にする
3. 保守性が上がる ＼(^o^)／

カプセル化などして重複するコードをなくす。

2 章

正常系と異常系を考えるべし。

そのために、要件をユースケースとして落とし込み、実際のコードをイメージするとよい。

3 章

「仕様は必ず変更される」

内容は 2 章とだいたい同じ。

4 章

1. これまでの章で作ったソフトウェアは顧客の要件を満たしているが(飼っている犬の鳴き声を聞いたらドアを開ける)
2. 実際の世界では犬の鳴き声は自分の犬以外にもたくさんあるので自分の犬の鳴き声だけをしょりさせないといけない ←分析して分かったこと

• 変更前: DogDoorクラスで犬の鳴き声を処理していた
• 変更後: BarkRecognizer クラスを新規に作成。BarkRecognizer で犬の鳴き声を処理するように委譲

委譲

委譲すると、ソフトウェアを疎結合に保つことができる。1 つの処理を変更するのに複数のクラスをいじらなくて済む。

ユースケースをもとにクラスを抽出する方法

• システムの一部を表現している名詞がクラスの候補(ここでは外部起動者の犬はシステムに含まれないので「システムの一部」ではない)
• ユースケース内の動詞はシステム内のオブジェクトのメソッド候補

5 章 と 6 章

大規模ソフトウェア開発

• 問題を小さく分割すべし
• フィーチャーを理解すべし
  • フィーチャーとはシステムが必要とする何かである
  • フィーチャーをもとに要件を深堀する
  • 本書ではフィーチャーは要件よりも上位のものとして扱っているが「『フィーチャー』と『要件』の違いはとくに重要ではないので拘るな」と言っている

7 章

アーキテクチャを設計する

• システムの本質をフィーチャーから選択する
  • システムの本質とは、そのフィーチャーが存在しなかったらシステムが成り立たないもの
• どのフィーチャーから着手してもよい
  • ただし各フィーチャーのリスクを先に洗い出しておくべし
  • リスクとは、そのフィーチャーが実装されないとシステムが成り立たないもの
• 次に取り組むフィーチャーは、最初に着手したフィーチャーに関係するものがよい
  • リスクを洗い出すまではコードを書かないこと

フィーチャーの意味が分からないときは顧客に尋ねよう

1. 顧客に尋ねる(このフィーチャーはどういう意味なの？)
2. 共通性を分析する(共通する処理は何か？)
3. 実装を計画する(コードに落とし込む)

8 章

オブジェクト指向の原則

開放閉鎖原則 OCP (Open/Closed Principle)

クラスは、拡張に開放され、修正に閉鎖されるべきである。

継承や委譲を使う。拡張するときは委譲先を変更するだけで済むし、修正するときに基底クラスを変更せずに済む。みたいな。

繰り返し禁止原則 DRY (Don't repeat yourself)

共通する事柄を抽出し、一箇所にまとめることで、コードの重複を防ぐ。

1つの要件を1箇所にまとめる。

単一責任原則 SRP (Single Responsibility Principle)

システム内の全オブジェクトは単一の責任を負い、オブジェクトのあらゆるサービスはその単一の責任を遂行することに集中すべきである。

SRP 侵害を発見する方法。

<クラス名> は自分自身を <メソッド名>

この文章が自然な意味にならない場合は SRP ではない。

リスコフの置換原則 LSP (Liskov Substitution Principle)

サブタイプは基底タイプと置換可能でなければならない。

本書では、継承、委譲、コンポジションを使って LSP を保てと言っている。

(「委譲」と「コンポジション」は違うんだっけ？)

4873113490