【９月２週目】オブジェクト指向設計実践ガイドを読んで【１／２】

オブジェクト指向設計実践ガイド〜Rubyでわかる進化し続ける柔軟なアプリケーションの作り方〜を読みました。オブジェクト指向の理解が足りていないと感じていたところ、普段使っているRubyでオブジェクト指向が解説されている本があると知り読み始めました。500ページものボリュームですが、印象に残った部分を自分なりにまとめていこうと思います。

オブジェクト指向設計とアジャイル

オブジェクト指向設計は途中からの変更を柔軟に行えるコードを作るために必要な考え方です。 プロダクトは一度作ってしまったら完成というわけではなく、後に仕様の変更や顧客からの要望によって改善が行われるので、柔軟に変更できる設計にする必要があります。近年ソフトウェア企業ではアジャイル開発という開発手法が多く採用されています。アジャイル開発というのはリリースしてユーザーからのフィードバックをもらい改善するというサイクルを早く行なってソフトウェアを作っていく開発手法のことで、そのメリットの多さから従来のウォータフォール型の開発のように最初に全ての使用を決め、変更など受け付けない開発手法からアジャイル開発に移行する企業も増えていると聞きます。そんなアジャイル開発の肝は「柔軟な変更」であり、それを実現可能にするのがオブジェクト指向設計なのです。 設計と聞くと最初から最後までもれなく仕様を決めるというイメージがありますが、オブジェクト指向設計の意味は真逆で、柔軟な変更が可能なプロダクトを作るために設計をするという思想です。

５つの設計原則

設計にはいくつかの原則が存在し、それらはあらゆる研究によって導き出され長く活用され続けています。代表的な原則にSOLIDというものがあり、オブジェクト指向設計で最もよく知られている５つの原則の頭文字を合わせて作られました。５つの内訳は次の通りです。

• S・単一責任（Single Responsibility）
• O・オープン・クローズド（Open-Closed)
• L・リスコフの置換（Liskov Substitution)
• I・インターフェイス分離（Interface Segregation)
• D・依存性逆転（Dependency Inversion)

こうした原則によって素早く柔軟に顧客の要望に応ることができ、アプリケーションの寿命を長くすることができます。逆にこういった原則を無視して、ルールを定めずに開発をしてしまうと変更に時間がかかってしまうなど多くの負債を抱えることになります。

その他メモ

なぜ単一責任なのか

再利用が容易になる

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