読者です 読者をやめる 読者になる 読者になる

「オブジェクト指向設計実践ガイド」 第2章 単一責任のクラスを設計する

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

メッセージに注目する前に、クラスに注目してみる。

クラスに属するもの

コードの書き方は知っているけれど、どこに置けばよいのかわからない」段階では次の2点を心がけよう。

  • メソッドをグループに分けクラスにまとめる

    クラスを作るとは、作りたいアプリケーションの世界をクラスによって分割すること。とはいえはじめの段階で適切に切り分けするのは不可能である。なので、次も心がける必要がある。

  • 変更がかんたんなようにコードを組成する

    TRUE(Transparent 見通しが良い, Reasonable 合理的, Usable 利用性が高い, Exemplary 模範的)なコードになるように気を配る

単一責任なクラス

変更が容易なアプリケーションは再利用しやすいクラスから構成される。再利用しやすいクラスの振る舞いは明確に定義され、外部への依存は少ない。

責任が多いクラスは、いろいろな場所で利用され、変更される理由が多い。このため、変更の度にそのクラスに依存する多くの箇所に破壊的な変更が必要になってしまう。クラスの再利用性を高めるためには、単一責任であることが重要。

クラスが単一責任かどうか確認するには、次のように考えてみること。

  • クラスのメソッドを「質問」に言い換えたとき、意味を成すかどうか

    「自動車」に対して運転手の名前を聞いてみる

  • 1文でクラスを説明できるかどうか

    説明の中に「and, or」が入っていたら危ない

クラス内のすべてがそのクラスの中心的な役割に関連していれば、そのクラスは凝集度の高い、よく設計されたクラスとなる。

変更に開かれたコード

アプリケーションに将来どんな変更があるかを知ることはできない。しかし、変更があるということだけは確実である。なので、事前に要求を予測して実装することは不可能だが、少なくともどんな要求が来ても変更がなるべく容易であるように備えておくことは良いことである。そのためにいくつかのテクニックが存在する。

  • データではなく振る舞いに依存する

    インスタンス変数・データの構造は隠蔽する アクセサメソッド、構造体を利用

  • あらゆる箇所を単一責任に

    クラスと同様、メソッドも単一責任であるべき。