「処理がひとつ」ではなく「変更する理由がひとつ」で、クラスを分ける

「経理の人に頼まれて直したら、画面の表示が崩れました」——SESの現場に長くいると、これに近い経験がある人は少なくないはずです。

「処理がひとつ」ではない

SOLIDの単一責任の原則は、しばしば「ひとつのクラスには、ひとつの処理だけを書く」と誤解されます。提唱したロバート・C・マーティンの定義は違っていて、「クラスが変更される理由は、ひとつであるべき」というものです。処理の数ではなく、変更の引き金の数を見ています。

目印は「誰の都合で直すか」

この違いが分かると、現場での見分け方が変わります。同じクラスを、経理の都合と画面の都合とで交互に直しているなら、それは分けどきのサインです。逆に、処理を機械的に細切れにしただけで、変更理由が結局ひとつしかないなら、無理に割る必要はありません。

関心の分離も、同じものさしで測れる

「関心の分離」もほぼ同じ基準で見ることができます。画面の見た目を直すために業務ロジックまで触らなければならない状態は、分離できていないということです。ファイルの行数やコメントの量とは関係がありません。

SESの現場でこれが効く理由

常駐先のコードは、自分が抜けたあとに別の会社の誰かが引き継ぎます。変更理由が混ざったクラスは、引き継いだ人に「これを直したら、関係ない画面まで壊れないか」という確認を毎回強いることになります。分けておくことは、次の担当者への申し送りを、コードの形で先に済ませておくことでもあります。

原則を知っているかどうかで、こういう判断がどれだけ変わるか——エンジニアの型の問題集で確かめてみてください。自分の仕事の流儀を知りたい人は、3分の自己診断もどうぞ。