5日目のゴール
5日目のテーマは
「1クラス1役割を“より強固にする”ための設計の深掘り」 です。
1〜4日目であなたはすでに、
- クラスは1人1仕事
- 依存の向きは上→下
- 役割ラベルで責務を明確化
- 未来の変更に耐える設計を考える
という“中級者の基礎体力”を身につけました。
5日目では、さらに一歩進んで
「役割を守るための境界線をどう引くか」
をファイル保存アプリを題材に学びます。
役割を守るための「境界線」を意識する
クラスは“担当範囲”を持つ
1クラス1役割を守るためには、
「このクラスはここまで」「ここから先は別のクラス」
という境界線を引く必要があります。
境界線が曖昧だと、
クラスはすぐに“なんでも屋”になります。
境界線が明確だと、
クラスは“専門家”として振る舞えます。
今日のテーマは、この境界線を
コードの構造としてどう表現するか です。
境界線の例1：Memo と MemoRepository の境界
Memo は「データの意味」だけを担当する
Memo はこういうクラスです。
public class Memo {
private final int id;
private final String date;
private final String body;
}
Memo が知っていていいのは
「メモとは何か」 だけ。
Memo が知ってはいけないのは、
- ファイルの保存形式
- 保存先のパス
- 画面表示
- ユーザー入力
これらはすべて境界線の外です。
Memo がこれらを知り始めた瞬間、
責務が崩れます。
境界線の例2：MemoRepository の担当範囲
MemoRepository は「永続化の専門家」
MemoRepository の責務は
「Memo を保存・読み込みすること」 だけ。
境界線の内側にあるのは、
- ファイルの読み書き
- 保存形式（ID|日付|本文）
- 一時ファイルでの再構築
- UTF-8 などの文字コード
境界線の外側にあるのは、
- ユーザー入力
- 画面表示
- メニューの制御
- Memo の意味的な判断（例：重要度など）
もし MemoRepository が
「保存しました！」と画面に出し始めたら、
境界線を越えています。
境界線の例3：App（UI）の担当範囲
App は「司会者」であり、裏方の仕事はしない
App の責務は
「ユーザーと会話し、適切な担当者に仕事を依頼する」 こと。
境界線の内側にあるのは、
- メニュー表示
- Scanner での入力
- MemoRepository に依頼する
- 結果をユーザーに伝える
境界線の外側にあるのは、
- ファイルの読み書き
- 保存形式の決定
- ID 採番
- Memo の構造
App がこれらをやり始めたら、
境界線が崩れます。
境界線を破ると何が起きるか
例：App が保存形式を知ってしまった場合
悪い例：
String line = id + "|" + date + "|" + body;
writer.write(line);
これを App に書いてしまうと、
- 保存形式を変えたいとき App を直す必要がある
- JSON にしたいとき App も修正対象になる
- DB 保存にしたいとき App が邪魔になる
つまり、
変更の波及範囲が広がる＝保守性が下がる。
境界線を守るとは、
「変更の波を最小限にする」 ということです。
境界線を守るための技術：メソッドの“置き場所”
「この処理はどのクラスに置くべきか？」を常に問う
例えば、ID 採番の処理。
private int getNextId() { ... }
これはどこに置くべきか？
答えは MemoRepository。
理由は、
- ID は保存形式に依存する
- ファイルの内容を読まないと決められない
- UI とは無関係
つまり、境界線の内側は Repository。
App に置くと境界線を越えます。
境界線を守るための技術：情報の“隠蔽”
クラスは「必要な情報だけ公開する」
MemoRepository の例：
public void save(Memo memo)
public List<Memo> findAll()
public boolean deleteById(int id)
public boolean updateBody(int id, String newBody)
公開しているのは
「App が必要とする操作」だけ。
逆に、内部処理は隠しています。
private Memo parseLine(String line)
private String formatLine(Memo memo)
private void replaceFile(Path temp)
これが 情報隠蔽（Encapsulation）。
境界線を守るための最強の武器です。
境界線を守るための技術：依存方向の固定
「上 → 下」だけ依存する
依存方向はこうです。
App → MemoRepository → ファイルシステム
App → Memo
MemoRepository → Memo
逆方向は絶対に発生させない。
MemoRepository → App
Memo → App
Memo → Repository
これらが起きると、
境界線が崩れ、保守性が一気に落ちます。
5日目の実践：自分のコードに“境界線チェック”をかける
次の質問を自分のコードに投げてみる
- このクラスは「他人の仕事」をしていないか？
- このクラスは「自分の仕事」をし忘れていないか？
- このクラスは「知る必要のない情報」を知っていないか？
- このクラスは「公開しなくていいメソッド」を公開していないか？
- このクラスは「依存してはいけない相手」に依存していないか？
これらに YES が出たら、
境界線が曖昧になっているサインです。
5日目で本当に掴んでほしいこと
今日のテーマは
「1クラス1役割を“境界線”として意識する」 ことでした。
まとめると、
- クラスには担当範囲（境界線）がある
- 境界線を越えると責務が崩れる
- 境界線を守ると変更に強くなる
- 情報隠蔽と依存方向が境界線を守る武器
- 境界線チェックで自分のコードを評価できる
あなたはもう、
「クラスを分けられる人」から
「クラスの境界線を設計できる人」 に進化しています。
次の6日目では、
この境界線をさらに強化するために
「インターフェース」という武器 を導入します。
