はじめに
クラスが巨大化する一番の原因は、役割が曖昧なクラス名にあります。
大雑把で意味がガバガバなクラス名は、用途が広すぎるため様々な処理が書かれてしまいます。
その結果、クラスが肥大化しやすくなってしまいます。
僕が今までで見てきた1000行を超えるような巨大クラスも、共通して曖昧なクラス名になっていました。
ここではクラス命名のアンチパターンとして、クラスが肥大化する名前を紹介します。
便利屋化しやすい「Util」
特定のオブジェクトや状態に依存せず、さまざまな場面で再利用できる「汎用的な処理」を静的メソッドとして集約したクラスが「Util」（ユーティリティ）クラスです。
例
- 文字列の分割・結合（split,join）
- 日付のフォーマット変換
- 四捨五入、切り上げ、切り捨て
しかし、String型やDate型といった基本的な型で必要になる汎用的な処理は無数にあります。
この無数にある処理をUtilクラスに定義されていくうちに、クラスは肥大化してしまいます。
共通というあいまいさの塊「Common」
アプリケーション内で特定の領域に共通して利用される処理が、このクラスに定義されやすいです。
「Util」クラスと同じように、汎用的な処理（静的メソッド）が大量に集約されてしまうケースが多いです。
あらゆる処理を定義して良いように見せる「Manager」
Managerという名前の通り、「管理する人」という意味があります。
こちらは「Util・Common」と比較すると、より複雑な処理が集約されがちになるクラス名です。
複雑な処理の割に、何を管理するのか？ 名前からは伝わってきません。
そのため、複雑で関心事がバラバラなクラス設計に陥りやすい名前です。
私の今までの経験上、この「Manager」と、
後述する「Controller」「Service」と名の付くクラスは、
特に処理が複雑かつ様々な関心事を抱えたとても厄介なクラスになっているケースが非常に多いです。
全部まとめて面倒を見がちな「Controller」
WebフレームワークのMVCモデルを採用しているアプリケーションでは、この命名を採用するケースが多いです。
コントローラークラスは本来、外部から受け取った様々なデータを他のオブジェクトに渡すことが責務です。
ビジネスロジックを書くべきではありません。
しかし「Controller」という名前自体があいまいなため、ビジネスロジックが書かれてしまいクラスが肥大化するケースが多いです。
ビジネスロジックのごった煮「Service」
サービスという名前も、ドメイン駆動設計で馴染みのある名前です。
上記のような設計パターンでは、頻繁に「Service」という名前が採用されます。
サービスクラスには主にビジネスロジックを記載しますが、クラス名が曖昧だと、様々なビジネスロジックを呼び寄せてしまい、クラスが肥大化してしまいます。
例として、ユーザー情報のCRUD操作を行うサービスクラス「UserService」があると仮定します。
このクラスではユーザー情報の登録・読み取り・更新・削除処理を行います。
しかしこれらの処理は、そもそもお互いの関連性がありません。
これは「UserService」という名前の意味が広すぎるのが原因です。
本来であれば、登録・読み取り・更新・削除 ごとにクラスを分けるべきです。
より具体的で意味のある名前を採用しよう
「名は体を表す」というように、名前は非常に強力な力を持っています。
開発者はクラス名を見て、「この処理はこのクラスに定義してよいか？」と検討します。
意味が曖昧なクラス名だと、開発者は「このクラスに定義しても違和感は無いな」と判断して、たくさんのロジックが集約されてしまいます。
反対に、明確な意味を持つクラス名にはそのクラス名に沿ったロジックが自然に集まりやすくなります。
名前がクラスの構造を左右するのです。
クラス名は慎重に検討して命名してするようにしましょう。