【見違える】知っておくべき設計原則|単一責任の原則

設計
  • 気付くとスパゲッティコードを量産している。
  • 仕様変更や機能追加のたび、影響調査やリグレッションテストに時間が掛かる。
  • カッコ良い美しいコードを書きたい。

こんな人には役に立つ考え方が「単一責任の原則」です。私はこの原則を知ってから徐々にスパゲッティコードの生産を止め、カッコ良い美しいコードを書けるようになりました。

IT業界歴10年以上、現在、フリーエンジニアとして活躍しておりますが、もっと早いタイミングで知っておけば良かったと痛感しております。

では早速、単一責任の原則についてみていきましょう。

単一責任の原則に従って設計することで不安定なクラスを解消

単一責任の原則とは、「クラスやメソッドを変更する理由は一つで無ければならない」という考えです。注意点として、この単一責任の原則の考えはそのクラスやメソッドの利用者にまで及ぶことです。

続いて、単一責任の原則の考えに従い設計すべきなのかについてみていきましょう。

何故、単一責任の原則に従って設計すると良いのか?

理由としてはシンプルで、一つのクラスやメソッドに対して複数の責任を持たせた場合、例えば、責任A、責任B、責任Cとすると、機能に変更が加わるとその影響は責任A、責任B、責任Cのすべてに影響することになります。つまり、非常に不安定なクラスやメソッドになってしまう訳です。

すべてに影響するので、当然リグレッションテストの対象になります。全く関係のない責任(機能)のリグレッションテストはやりたくないですよね。

1つのクラスやメソッドには1つの責任(機能)を持たせるようにすることで、よりクラスやメソッドがお互いに疎結合になり、たとえあるクラスに変更が生じても、そのクラスだけに影響を閉じておくことが出来ます。

分かりにくいと思うのでもう少し具体例もみておきましょう。

単一責任のようで利用者が異なる具体例

例えば、パソコンクラスがあったとします。このパソコンクラスを利用するのはパソコンの使い方を知らないおばあちゃんかもしれません。逆に、パソコンの使い方に熟知した天才ハッカーかもしれません。

このように利用者が複数想定される場合はクラスやメソッドについても分割しておくと良いです。ただし、分割が行き過ぎると折角まとまりのあったモジュールがバラバラになり分かりにくいものになってしまうかもしれません。何事も程々にしておくことが大切ですね。

さいごにまとめ

単一責任の原則とはクラスやメソッドを変更する理由は一つで無ければならないという考えです。そして、その考えは対象のクラスやメソッドの利用者にも及びます。しかし、やりすぎるとモジュールのまとまりがなくなる危険があるので程々にしておきましょう。

頭では分かっていてもなかなか実践は難しいものです。どんどんアウトプットして自分なりに『単一責任の原則ってこういうことか!』と気付いていただけたらと思います。

読みやすいコードを書くためのテクニックや考え方を解説している本として下記の2冊をオススメします。


それでは、最後まで読んでいただきありがとうございました!

コメント

タイトルとURLをコピーしました