　『Head First オブジェクト指向設計』を読み始めた。顧客志向の考え方が非常に良いと思う。コードを書いてWebアプリケーションを作る目的は顧客の要望を叶え、必要な機能を提供することなのだ。コードが汚いとかきれいとかは結局、顧客にとっては関係ない。
　とはいっても、結局汚いコードでは、継続的に顧客が望む安定的なシステムや機能の新規追加は提供できない。またそういうコードを毎日見るのはしんどく、深夜まで作業するハメになる。この章では顧客の要望を叶えることが最優先でありつつも、オブジェクト指向で設計を改善し続けていく、そのための方法を身に着ける。
　第1章のタイトルは「よく設計されたアプリケーションは心を動かす」。つまり、設計がしっかりされたアプリケーションは、変更や機能の追加、保守が容易なため顧客とプログラマの両方を満足させるのだ。

第1章

素晴らしいソフトウェアにするための3つのステップ

顧客が必要とする処理を､ソフトウェアが実行するようにする｡
そのための要件収集と分析
顧客を喜ばせることが最優先。オブジェクト指向設計の改善はその後。
オブジェクト指向の基本原則を適用し､柔軟性を高める
保守と再利用が可能な設計を追求する

合致しないオブジェクトの謎

オブジェクトは名前が示す処理を行うべきである
Jet(ジェット機)という名前のオブジェクトであれば、離陸takeOff(), 着陸land()というメソッドは持つべきだが、搭乗券を受け取るtakeTicket()という仕事は行うべきではない。
オブジェクトは1つの概念を表現すべきである。
使用されていないプロパティは決定的な証拠である。
プロパティに値がない状態で頻繁に使用されているオブジェクトがあれば、そのプロパティは別のオブジェクトに持たせるべきプロパティである可能性が高い。

重複するコードをみたら、カプセル化すべき場所を探せ。

カプセル化の目的はアプリケーションの一部にある情報を、他の部分から保護すること。
最も単純な場合、クラス内のプロパティをprivateにすれば他の部分からそのデータが保護される。保護すべき情報は、ギターの詳細のような、プロパティの集合全体(GuitarSpec)であったり、アヒルの飛び方(LowFly, HighFly)のような振る舞いであったりする。
クラスから振る舞いを分離すれば、クラスを変更しなくても、振る舞いを変更できる。
アプリケーションの様々な部分を分割すれば、他の部分を全く変更することなく、その部分を変更できる。
アプリケーション内で変動する部分(流動的な要素)を、同じ状態にとどまり続ける他の部分(固定的な要素)と分離して、カプセル化すべき。

用語理解

柔軟性
毎回作り直さなくても、ソフトウェアの変更と成長が可能となるようにする。アプリケーションが脆弱になるのを防ぐ。
必要とされる処理をソフトウェアが実行するようになると、柔軟性が大きな問題となる。
顧客が新しいプロパティや機能を追加したいとき、コードの重複が山程あり、継承構造が混乱していたら、変更は苦痛になる。
カプセル化や良いクラス設計などの原則をコードに導入すれば、変更は容易になり、アプリケーションがはるかに柔軟になる。
カプセル化
コードの変化する部分を分離し、別の部分は変化しなくてもすむように、これを使う。そして何も壊さずにコードの変更が行えるようにする。
機能
これがないとアプリケーションの設計がどんなに良くても、顧客は満足しない。
デザインパターン
再利用を確実に行い、他の誰かがすでに解いている問題を再び解かないようにする。

委譲とは

委譲とは、あるオブジェクトが何らかの仕事を行う必要があるときに、直接行うのではなく、別のオブジェクトにやってもらうこと。
Javaの一般的な委譲はequalsメソッド。委譲によって各オブジェクトは等価性を自分で処理するようになる。
今回の場合、Inventoryのsearch()メソッドの中でGuitarSpecオブジェクトの比較を行うのではなく、GuitarSpecオブジェクトに等価性の比較を行わせる。

疎結合とは

疎結合とは、アプリケーション内のオブジェクトが自分の仕事だけに専念している状態。よく設計されたアプリケーションは各々のオブジェクトが1つの役割に専念し、シンプルなオブジェクトの多数の集合体となる。各オブジェクトは他のオブジェクトから独立しているので、別のオブジェクトを変更することなく、あるオブジェクトの振る舞いを変更できる。