SRP（単一責任の原則）とは何か
SRP は
👉 Single Responsibility Principle
日本語だと主に 単一責任の原則 と呼ばれます。
SRP を一言でいうと
「1つのクラス（モジュール）は、1つの責任だけを持て」
もう少し実務寄りに言うと：
「そのクラスが変更される理由は、1つだけにしろ」
となります。
この後者の言い方がめちゃくちゃ大事なんですよ。
「責任」って何？
ここで言う責任は
「機能」ではなく「変更理由」です。
例えばこんなクラスがあるとしましょう↓
class Player {
void Update(); // ゲームルール変更で変わる
void Draw(); // 描画方式変更で変わる
}ゲーム仕様変更、描画仕様変更。
これらはどちらも変更理由です。
よってこれはSRPの規則には沿っていません。
SRPを守るとどうなる？
良いこと
- 変更が局所化する
- バグの波及が減る
- クラス名＝役割になる
- 「ここ触っていい場所」が明確
これらによってデバッグが早くなりますし、実務においては必要な機能が限定されているためレビューも楽になります。
それと、数ヶ月後の自分に感謝されます(*´艸`)ｳﾌﾌ
以下は注意！(｀･д･)σ
❌ 「クラスは小さければいい」
→ 小さくても責任が混ざってたらアウト。
❌ 「1メソッド1クラス」
→ やりすぎ。逆に読みにくくなる。
ここで勘違いされるのですが、プログラミングにおいてコード量が多い事が悪い事で、少なければ良いという風潮がぽつぽつと見られます。
しかしそれは大きな誤解です。
コード量が少ないほうが良いという認識はおそらく、コードを読む量が少なくなる事で余計な工数（手間）が減るから、という理由があるからだと思いますが、実際にはコード量と可読性は水と油のように相容れないものです。
実際には冗長に書かれたコードが読みやすい可能性も十分にあります。
（こう発言すると俄かに信じ難いように聞こえますが事実としてあるのです）
なので、コード量が増えたからダメだ、リファクタリングだ～と騒ぎ立てるのではなく、例えば一旦深呼吸するなり、次の日なりに改めて全体を眺めてみてください。
本当に読みやすいコードは、見ただけでどんな事が行われているか雰囲気で把握できるコードです。
それを忘れないようにしましょう。
責務の分離まとめ
クラスを定義する前にまずはこれについて考えてみましょう👇
- このクラスは何の専門家なのか？
- 何を知っていていい？
- 何を知らなくていい？
- いつ変更される？
- 他のクラスに何を頼む？
まずはこれらです(*^-^*)
上記についてよく分からないという場合は、もう少し落ち着いてコードを整理してみましょう。
固定概念は外して考える事が必要になってくるかもしれません。
また無理にクラスにするべきではない、という選択肢も良い選択かもしれません。
クラスを定義する際には、必ず責務を明白にすること。
これ大事＼_(｡･∀･)
クラスは「責任の境界線」
- 1クラス = 1つの専門家
- 1クラス = 1つの変更理由
- 名前で役割が分かる
- 振る舞いを持つ
クラスを作る事は単純に見えて、かなり難しい作業です。
なぜなら、一度定義したクラスは今後常に使い続けるものだからです。
以後常に付き合っていくという事は、そこで間違ってしまうとその後も間違いを引きずっていく事になり、完成形に近づくにつれてしんどくなります。
そうならないためにもクラスを作る時は、繊細かつはっきりとした役割を持たせたものを作っていきましょう。
現実的な理想として、最初から完璧を求めないようにする事がポイントです。
- まずは少し大きめにクラスを作る
- 変更理由が明確になったらすぐクラスを分割する
- 責務が言語化できたら名前を変える
クラスはじっくりと入念に作り上げていくものです。
リファクタリングとは、そういう時にこそ実践するものである事を覚えておいてほしいです(ﾟ∀ﾟ)
今回は以上になります。いかがでしたでしょうか？
またC++のプログラミング講座は不定期ですが、書いていこうと思います。
ロックマンの開発をしながら得た知識もたくさんあって、私も日々精進します！(｀･ω･´)ゞ
また間違ってるところなどあったらコメントで教えてくださるとありがたいです。
皆さんのプログラミング・ライフの足しに少しでもなる事ができれば幸いです。
では、また(@^^)/~~~
コメント