オブジェクト指向設計実践ガイド 第4章
パブリックインターフェースについての話。デメテルの法則についても触れていました。
第4章 柔軟なインターフェースを作る
- オブジェクト指向アプリケーションは「クラスから成り立ち」「メッセージによって定義される」
- オブジェクトの責任 ＝ オブジェクトが何を知っているか
- オブジェクトの依存関係 ＝ オブジェクトが誰を知っているか
4.1 インターフェースを理解する
- オブジェクト同士が複雑に依存してしまうような設計の問題は、クラスが何を「する」かでなく、何を「明らかにする」か、の視点が欠けていることにある
- 他のオブジェクトからの利用が意図されているメソッドが、そのクラスのパブリックインターフェースを構築する
4.2 インターフェースを定義する
- レストランの厨房から見て、お客さんが使うことが期待されるパブリックインターフェースはメニュー
- メニューを使うことで厨房が「どのように」料理を作るかを関知させず「何を」望むかをお客さんに頼ませることができる
- パブリックインターフェースの特性
- クラスの主要な責任を明らかにする
- 外部から実行されることが想定される
- 気まぐれに変更されない
- 他者がそこに依存しても安全
- テストで完全に文書化されている
- パブリックインターフェースはクラスの責任を明確に述べる契約書
- 「変更の可能性が低いところにのみ依存する」という考えはクラス内のメソッドにも当てはまる
4.3 パブリックインターフェースを見つける
- ドメインオブジェクト ＝ アプリケーションにおいてデータと振る舞いの両方を兼ね備える名詞を表すもの
- 設計時にはドメインオブジェクトに集中はせず、オブジェクト間のメッセージに注意を向ける
- ドメインオブジェクトには「気づく」
- オブジェクトとメッセージを実験するにはシーケンス図を使うと良い
- パブリックインターフェースをあらわにし、実験し、定義するための手段となる
- メッセージに集中することを助け、テストで最初に明らかにしたいことへの合理的な見当をつけられるようになる
- メッセージに基づく視点はクラスに基づく視点よりも柔軟なアプリケーションを生む
- オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
- パブリックインターフェースが小さい ＝ 他から依存されるメソッドがわずかしか無い
4.4 一番良い面（インターフェース）を表に出すコードを書く
- インターフェースこそが全てのテストや他のどんなコードよりもアプリケーションを定義し将来を決定づける
- プライベートメソッドは全くテストしない、もしくはパブリックなメソッドからは隔離する
- 不安定なプライベートメソッドに依存するテストを書かない
- 外部フレームワークへの依存は技術的負債の一形態である
- パブリックインターフェースを構築するときは、他者に要求するコンテキストが最小限になることを目指す
- メッセージの送り手が、クラスがどのように振る舞いを実装しているかを知ることなく、望むものを得られるようにする
4.5 デメテルの法則
- デメテルは3つ目のオブジェクトにメッセージを送る際、異なる型の2つ目のオブジェクトを介すことを禁じる
- 「直接の隣人にのみ話しかける」
- 中間オブジェクトを介して遠くの属性を取得することが最も低コストな場合もある
- 変更のコスト・頻度と、違反修正のコストを比べてバランスをとる
- デメテルの法則を違反することで負うリスクは安定した属性に対しては低い
- メッセージチェーンを除去する方法の1つは、メッセージを移譲すること
- 結合を隠しただけで実際にはコードの結合が解かれていないような場合もある。移譲は注意して行うこと
- メッセージに基づく視点でメッセージを見つけたなら、そのメッセージは何らかのオブジェクトのパブリックインターフェースとなる
- そのオブジェクトが何のオブジェクトかはメッセージ自体が導いてくれる
4.6 まとめ
- オブジェクト指向アプリケーションは、オブジェクト間で交わされるメッセージによって定義される
- メッセージの交換はパブリックインターフェースに沿って行われる
- メッセージが「受け手がどのように振る舞うか」を伝えるのではなく、相手を「信頼」し送り手が望むことを頼むものであるとき、柔軟なパブリックインターフェースを自然に進化させていく
オブジェクト指向設計実践ガイド 第3章
読み進めるうちにしばしば「あのプロダクトのあの実装はこういう意図だったのでは！」と気づいて、その瞬間が気持ち良い。
第3章では特に「他クラスへのあるメッセージ送信についての依存を、そのメッセージに応答できるダックタイプへの依存に変えるとき、それはインタフェースを定義している」という趣旨の文に唸らされた。
3章 依存関係を管理する
- オブジェクトが現実世界の問題の特徴を反映し、オブジェクト間の相互作用が解決策を用意する
3.1 依存関係を理解する
- テストはコードを参照するがゆえに、コードに依存する
- テストに慣れないうちはコードと過度に依存したテストを書きがち
3.2 疎結合なコードを書く
- 依存オブジェクトの注入によるコード整形は、クラス名やそのクラスに送るメソッド名を知っておく責任が他のクラスにあるのでは、と疑える能力に左右される
- コントロールできない外部のクラス名に対する依存をどのように管理するかはアプリケーションに多大な影響を及ぼす
- 複雑なメソッドはそうでないメソッドよりも変更が必要になる可能性が高い
- 引数が必要なメッセージを送るとき、送り手は引数についての知識を持たざるをえない
- 真偽値を引数にとったり引数の false と nil を区別したいときは
||でなくfetchを使うのが良い - 自身のアプリケーション内のクラスは自身のアプリケーションが所有するコードのみに依存するべき
- 他クラスのインスタンス作成のみを目的とするクラスをオブジェクト指向設計ではファクトリーと呼ぶ
3.3 依存方向の管理
- 各クラスの依存は自分より変更されないクラスへの依存となるように管理する
- 依存する他クラスへのメッセージに応答できるダックタイプを定義する ≒ インタフェースの定義
- 抽象化されたものへの依存は具象的なものへの依存よりも常に安全
3.4 まとめ
- 依存関係の管理において鍵となるのはその方向を制御すること
"オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方" を読み始めた
2度目のパーフェクト PHP の読了を果たした一昨日から、オブジェクト指向設計実践ガイドを読み始めた。
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz,?山泰基
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: 大型本
- この商品を含むブログ (1件) を見る
RubyKaigi の頃あたりに 訳しました:「オブジェクト指向設計実践ガイド」 - Misoca開発ブログ のエントリを読んで気になりつつ終ぞ今日まで読むには至っていなかったのだけど、同僚の @kymmt90 が読んでいていい感じとのことだったので読み始めた。まだ2章までしか読めてないけれど、既に面白い。
もうしばらくすると仕事でガッツリ Ruby を書くことになりそうなので、そのためのリハビリも兼ねている。
今年はオブジェクト指向設計やデザインパターンといった、将来つらくならない開発するための体系的な知識を付けたい気持ちがある。
理解を深めるためにも、メモを付けつつ読んでいこうと思う。
第1章 オブジェクト指向設計
- オブジェクト指向設計の失敗はコーディングテクニックでなく視点の置き方にある
1.1 設計の賞賛
- オブジェクト指向とは依存関係を管理すること
- 知識を持ちすぎたオブジェクトは制約が増えテスタビリティが下がるだけでなく、複製もされやすくなる
- 実用的な設計は未来を予測・選択するのではなく、あとにでも設計ができるよう変更コストを下げる
1.2 設計の道具
- 設計における道具は「原則」と「パターン」
1.3 設計の行為
1.4 オブジェクト指向プログラミングのかんたんな導入
- 手続き型言語：データと振る舞いが完全に独立している
- オブジェクト指向言語：振る舞いを持つオブジェクトがデータをカプセル化する
1.5 まとめ
- 実践は常に理論より物事を知っている
- 実践とは配られたカードの中でベストを尽くすことの積み重ね
第2章 単一責任のクラスを設計する
- オブジェクト指向設計のシステムの基礎は「メッセージ」
2.1 クラスに属するものを決める
- 設計はアプリケーションの可変性を保つために技巧を凝らすことであり完璧を目指す行為ではない
- 変更しやすいコード ... "TRUE" なコード
- Transparent: 見通しが良い
- Reasonable: 合理的
- Usable: 利用性が高い
- Examplary: 模範的
2.2 単一の責任を持つクラスをつくる
- 短絡的な再利用はクラスの目的を曖昧にし責任を増やす
- 単一責任の原則は「クラスがすることは全てそのクラスの目的に強く関連すること」を求める
- 何もしないことによる将来的なコストが今と変わらなければ設計の決定を延期する
- 決定は必要なときにのみ、その時点で持っている情報を使って行う
2.3 変更を歓迎するコードを書く
- インスタンス変数は大抵の場合アクセサメソッド等によってオブジェクトとして扱えるようにするのがよい
- メソッドもクラス同様に単一の責任をもつべき
- メソッドを単一責任にするためのリファクタリングは最終的な設計が見えない状況でもするべき
- 隠蔽されていたクラスの目的が明らかになる
- メソッドにコメントする必要がなくなる
- アプリケーションにとって健康的なコードの書き方（再利用）を促進する
- メソッドの移植性が高まる
