スマートフォン用の表示で見るかまずにまるのみ。第2部「アジャイル設計」の自分用まとめ。「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。(目的や意図がわかりにくい)原則システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。無条件で原則に従うと「不必要な複雑さ」を招くこともあるので注意。Principle)ざっくりクラスを変更する理由は1つ以上存在してはならない。Principle)ざっくり拡張に対して開いていなければならない(Open)修正に対して閉じていなければならない(Closed)拡張に対して開かれている仕様変更があった場合、振る舞いを追加することで変更に対処できる。修正に対して閉じている振る舞いを追加しても既存のコードは影響を受けない。Principle)ざっくり派生型はその基本型と置換可能でなければならない。要約読んでもよくわからないので詳しくここで望まれるのは、次の述べるような置換可能な性質である:S型のオブジェクトo1の各々に、対応するT型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型であると言える。ねこととりと赤いもの上記の引用の例をねこととりと赤いものに例えてみる。ねこがS型のオブジェクトo1ねこにだっこされている赤いものがT型のオブジェクトo2とりがTを使って定義されたプログラムPねこ(o1)は赤いもの(o2)を含む。とり(プログラムP)は赤いものを使う。とりに対して赤いものの代わりにねこを使ってもとりの振る舞いが変わらない場合、SはTの派生型。これはリスコフの置換原則に従っている。とりにねこを渡してとりの振る舞いが変わってしまう場合は、リスコフの置換原則に従っていない。Principle)ざっくり上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。上位モジュールと下位モジュール上位モジュールアプリケーションの方針に基づく重要な判断ビジネスモデルアプリケーションの存在理由を決定づける下位モジュール上位モジュールの実装の詳細を担当インタフェースの所有権は誰に上位モジュールが下位モジュールに依存している場合、問題を抱えてしまう。下位モジュールの変更が上位モジュールに影響を与えてしまう上位モジュールの再利用が難しい下位モジュールが宣言したインタフェースに上位モジュールが従う形は、インタフェースの所有権が下位モジュールにある状態といえる。逆に上位モジュールがインタフェースを宣言し、下位モジュールはそれに従う形にすることで、インタフェースの所有権を上位モジュールに持たせることができる。抽象に依存する具体的なクラスに依存せず、プログラム内の関係は抽象クラスかインタフェースで終わるようにする。Principle)ざっくりクライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。利用していないメソッドに依存してしまうと、そのメソッドが変更されたときに本来無関係であるはずのクライアントまで影響を受けてしまう場合がある。インタフェースを分離するそれぞれのクライアントが実際に利用するメソッドだけに依存するようにする。関連性を持ったインタフェースはグループ化し、クライアントごとに特化したインタフェースを用意。これによりクライアントは、自分が利用しないメソッドとの依存関係を断ち切ることができる。無条件で原則に従わないたとえば「単一責任の原則」では1つのクラスが1つの役割を持つことが求められているが、2つの役割が必ず同時に変更されるようなケースで無理に分離させると不必要な複雑さを生んでしまうことがある。設計でガッチガチに正規化した結果、クライアント側の手順が複雑になってしまうケースなどに通じるものがあるように思う。上記と同様、抽象もむやみやたらに使えばよいというものではない。以下はオープン・クローズドの原則の章から引用。開発者が担当する部分で最も頻繁に変更されるプログラム部分にだけに絞って抽象を適用するように努めるべきである。早まった「抽象」をしないことも、「抽象」を使うのと同等に重要なことなのだ。早まった「抽象」をしないことと「抽象」を使うことは同じように大事。Contract)事前条件と事後条件これから設計するクラスに関する契約を明文化することでリスコフの置換原則(LSP)を適用できるようになる。この「契約による設計」では、各々のメソッドについての事前条件と事後条件を前もって取り決めておく。派生型の事前条件と事後条件のルール派生型の条件には以下のようなルールがある。基本型の事後条件をすべて含んでいなければならない基本型に課せられている事後条件を無視した振る舞いを許可しない条件の明文化これらの契約内容はコメントやユニットテストなどで記述しておくとよい。思ったこと上記の原則に沿うような設計を心がけることで、オブジェクト指向らしい設計に近づく気がする。クラス設計時のポイントを押さえておくみたいな感じ。原則やデザインパターンの章を読んでてたびたび思うのが、以前関わっていたプロダクトやライブラリのコードについて「あーあの設計はそういう意図だったのかー」とか「だからあの実装になっていたのかー」ってこと。自分が感覚頼りで設計していたことを痛感させられたり、もやもやしてたところが明確化されてすっきりしたりでおもしろい。アジャイルソフトウェア開発の奥義では、上記の原則についてそれぞれ詳しい説明と設計の例が掲載されている。Strategy「オブジェクト指向のこころ」読書記録。視野を広げる「オブジェクト指向のこころ」読書記録。Adapter「オブジェクト指向のこころ」読書記録。(16)Profileid:tdakakよく噛んで食べたい。DeckTwitterTumblrpixivはてなブログをはじめよう!tdakakさんは、はてなブログを使っています。あなたもはてなブログをはじめてみませんか?はてなブログをはじめる(無料)はてなブログとはかまずにまるのみ。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。