【オブジェクト指向設計実践ガイド】第2 章単一責任のクラスを設計するを読んで学んだことをざっくりまとめてみた

クラスとは

クラスとは、あるオブジェクトに関する変数と、あるオブジェクトに関する処理を一つにまとめたものです。

クラスを定義するメリット

個人的には以下のメリットがあるのかなと考えました。

クラスを定義することで、仕様変更に対する影響範囲(変数の追加や、処理の変更)をクラスに局所化できる。
クラスを定義することで、同じ性質のオブジェクトを簡単に作ることができて、再利用性が高くなる。同じようなコードをもう一度書かなくて良くなる。
クラスを定義することで、コードのまとまりを意味のあるまとまりとして管理することができる。

ドメインとは何か

ドメインとは、アプリケーションが対象とする問題領域のことです。問題領域とは、解決すべき問題が潜んでいる領域のことです。ドメインを分析して構成概念を抽出することをモデリングと呼びます。モデリングの結果、得られた概念のことをドメインモデルと呼びます。ドメインモデルは、その概念に関連する属性と振る舞いを持ったオブジェクトとして定義されます。

このドメインモデルをコードで表現する際に、クラスを用います。

メソッド、手続き、振る舞いの違いとは

メソッドと手続き、振る舞い(オブジェクト指向における振る舞いは、オブジェクトの動作の仕方を表している)はどれも、一定の処理をまとめて抜き出したものです。そのため、概念的には同じなので、特に違いを意識する必要はないでしょう。

DRY原則の本質

私がRailsを勉強してたとき、「繰り返しはよくない」と散々言われてきて、そのようなこともあり、DRY原則は「同じようなコードを繰り返しは書くな」という意味だと思っていました。似たようなコードがあった場合、ひたすら共通化していました。

しかし、DRY原則の本当の意味は、「同じようなコードを排除することで、コードの変更箇所を一箇所に限定すること」ってのを最近知りました。つまり、「同じようなコードを排除してコード量を減らすこと」が目的なのではなくて、「変更箇所を一箇所に限定して、変更コストを最小限にすること」が目的なのです。

あと、DRY原則を適用させる上で注意すべきことは、何でもかんでもDRY原則を適用させるべきではないということです。DRY原則を適用させるということは、つまり、コードを共通化するということです。コードを共通化することによって、逆に変更コストが高くつく場合もあります(コードを共通化するということは、使われる場所に応じた独自の処理を追加できないということを意味します)。そのため、状況に応じて、メリットデメリットを考えて、DRY原則を適用させるかを判断するようにしましょう。