オブジェクト指向設計実践ガイド１章と２章読んだ感想

オブジェクト指向設計実践ガイドという本を読み始めた。オブジェクト指向設計を意識して責務を分けコードを書くことができるとか、拡張性を考えてコードを書くことができるとか、このあたりの知識が弱いと思っていて、この本を読んでそのあたりの知識をつけていけたらなと思う。

1章オブジェクト指向設計

一通り読んだ感想として、「変更に強いことが大事」というのが、言い回しを変えて、繰り返し書かれているのが印象的だった。アプリケーションが変更されるのは、重力みたいなものなので、その変更コストをどう抑えるのかみたいなところを考えると、変更に強いことがすごく重要になるという話。以下、本で気になったところ箇所抜粋

設計が解決する問題
- 要件の変更はプログラミングにおける摩擦力と重力
- 変更が容易なアプリケーションを書けるようにする
- 「あとにでも」設計できるようにする。変更コストの削減
原則
- SOLIDというオブジェクト指向設計でもっともよく知られる５つの原則がある
  - 単一責任
  - オープン・クローズド
  - リスコフの置換
  - インターフェース分離
  - 依存性逆転
設計パターン
- いわゆるGang of Fourと呼ばれるもの
- 「設計プロダクトの柔軟性、モジュール性、再利用性、理解のしやすさ」をより高めてくれる

2章単一責任のクラスを設計する

一通り読んだ感想として、「単一責任にするのは、再利用しやすいため」ということがすごく伝わった。また、変更を歓迎するコードとして、良く知られてる方法の一つに、「データではなく、振る舞いに依存するようなコードを書く」というのもすごく勉強になった。インスタンス変数や構造が複雑な配列を直接参照してて、そのデータに変更が発生した場合、その変更に合わせて参照してたところを全部修正するのは、かなり手間が発生するので、直接データを見るんじゃなくて、それを包むメソッドを作って（メッセージを受け取ると、データにアクセスする振る舞いをするメソッドを作って）、アクセスした方が良い。あと、題材になってた、自転車のギアとギアインチの関係を理解するのが、ちょっと頭痛かった（ただの算数だけど、なんか頭に入ってこなかった。。。）以下、本で気になったところ箇所抜粋

f:id:shimabukuromeg:20190102164250j:plain

なぜ単一責任なのか
- 再利用が容易になる
  - 2つ以上の責任を持つクラスは再利用が簡単ではない
クラスが単一の責任かどうか見極める方法
- クラスのもつメソッドを質問に言い換えた時、意味をなす質問になっているかどうか
変更を歓迎するコードを書く。データではなく、振る舞いに依存する（データに依存するのはよくない）
- 良くない理由は、データが変わった時に、それを参照してる箇所を全て修正しなきゃいけないから
- データではなく、振る舞いに依存するよう、特定のデータにアクセスするようなメソッドを作って、そのメソッド（振る舞い）を使ってアクセスする
- 例えば、インスタンス変数に結びついているようなコードはよくなくて、インスタンス変数を隠蔽するよう、インスタンス変数へのアクセスできるメソッドで包む
- 配列など、複雑なデータ構造への依存はさらによくない（データに依存するのはよくない）
  - 配列のデータ構造が変わると、それを参照してるコードを全て直さなきゃいけなくなる。なので、データ構造の隠蔽するようにする
    - 複雑な構造への直接の参照は混乱を招く問題があるので、意味と構造を分けれる
      - 意味と構造を分けるとは？
        
        意味（タイヤの直径を知りたい）と構造（配列を直接参照する複雑な構造）が一つのメソッドの中にあったところを、意味と構造を分け、diametersメソッドと構造を作るwheelfyメソッドを用意したってこと？
      - Structクラスを使って、構造を包み隠す。Structクラスは、明示的にクラスを書くことなく、いくつもの属性を１箇所に束ねるための便利な方法
Structサンプルコード