CONTENT
お疲れ様です。エンジニアのMです。
似たようなコードや機能を見るとついついコードを共通化したくなりますよね。
「これ他でも使えるから、共通化しよう！」
「色んなところで使えそうだから上位のクラスに持たせよう！」
と考え再利用できるモジュールを共通化することは、良いコーディングを目指すうえで必要なことだと思います。
ただ、これが行き過ぎてしまうとカオスな共通化クラスを生み出してしまうことになります。
「既に似たようなものが共通クラスにあるから再利用したい…！」
「でもそのままだと使えないからフラグを付けよう！」
「やっぱりこっちでも使えるようにしたいから引数を可変にしよう！」
などなど、当初の想定は同じような記述を避けるために共通化していたはずなのに、いつの間にか共通化するために他のコードの可読性を落としてしまったり、せっかくの共通化クラスの可読性が落ちてしまっていたりしませんか？
私自身も同じような体験をしたことがあります。
そこでうまく基準を考えられないかなという時に知ったのが単一責任原則です。
・単一責任原則とは
「クラスまたは関数は、単一の機能について責任を持つ」
「そのモジュールを変更する理由はひとつだけであるべき」
という原則です。
なかなか難解ですが、一つのクラスや関数に複数の役割を持たせてはいけないということです。
例えば、ユーザーの機能を扱うUserというクラスがあったとします。
ここに
save_user …ユーザー情報を保存する
send_mail …ユーザーにメールを送信する
create_u_report …ユーザーレポートを生成する
という処理をまとめたとしましょう。
このUserクラスは「ユーザー情報の保存」「メールの送信」「レポートの生成」という複数の役割（責任）を持っています。
これではクラスが肥大化し変更が難しくなるため、それぞれの役割のクラス（関数）に分割しましょう！ということです。
この役割を跨いで共通する処理は、使う用途が違うので、似たようなものも別々にしておいた方が良いのです。
単一責任の原則を意識することで、コードの品質を高め、メンテナンス性を向上させることができます。
是非活用して良きエンジニアライフを！