始めに
「気付いたらクラスの責務が増えていた。」
開発を続けていると、このような状況は珍しくありません。しかし、本当に原因は設計力の不足なのでしょうか。実は、多くの場合は設計そのものではなく、その前段階である要件の整理に原因があります。この記事では、責務が曖昧なクラスが生まれる理由と、要件との関係について解説します。
責務は実装中ではなく、要件から増え始める
責務が増えたクラスを見ると、「設計ミスだった」と考えがちです。しかし、設計者が最初から何でも詰め込もうと考えていたケースは多くありません。多くは機能追加のたびに、「この処理もここで対応しておこう」と判断した結果です。
では、なぜその判断が繰り返されるのでしょうか。その理由は、何を実現し、何を実現しないのかという境界が曖昧だからです。境界が決まっていない以上、新しい要件が現れるたびに「このクラスでも対応できそう」と判断され、責務が少しずつ増えていきます。
要件が曖昧だと責務も曖昧になる
例えば「ユーザー情報を管理する」という要件だけが定義されていたとします。この表現だけでは、
・登録する責務なのか
・更新する責務なのか
・認証まで担当するのか
・メール送信も含むのか
といった境界は分かりません。その結果、実装時の判断に委ねられます。
担当者が変われば判断も変わり、機能追加のたびに新しい責務が積み重なっていきます。つまり、責務が曖昧なのではなく、要件が責務を決められる粒度まで整理されていないのです。
設計は責務を考える作業ではない
設計では責務を決めると思われることがあります。しかし実際には、設計は要件で決まった責務を構造へ落とし込む工程です。要件で境界が決まっていない状態では、設計者は実装しながら責務を決めるしかありません。その場の判断で追加された責務は、後から見ると一貫性がなくなります。
これが「何でもできるクラス」が生まれる典型的な流れです。
責務を減らすには設計より先を見る
責務を減らそうとしてクラスを分割しても、要件の境界が曖昧なままでは同じ問題が繰り返されます。重要なのは、設計を始める前に、「このクラスは何を担当し、何を担当しないのか」を要件として明確にしておくことです。責務は設計で生まれるものではありません。
要件で定義され、それを設計が形にします。この順序が逆になると、責務は実装のたびに増え続けることになります。
まとめ
責務が曖昧なクラスは、設計者の技術不足だけが原因ではありません。多くの場合は、要件の段階で責務の境界が定義されていないことが原因です。設計は、その境界をコードへ落とし込む工程に過ぎません。だからこそ、保守しやすい設計を実現するには、「どう設計するか」だけでなく、「要件としてどこまでを責務と定義するか」を先に考えることが重要です。
コメント