1日目のゴール
中級編の1日目は「オブジェクト指向の本質＝1クラス1役割」を“体で理解する”こと。
今日のテーマは 責務（Responsibility）・分離（Separation）・保守性（Maintainability） を、ファイル保存アプリを題材にして深く掘り下げます。
初心者の頃は「動けばOK」でコードを書くことが多いですが、
中級者は “コードが育つ未来”を見据えて設計する 必要があります。
その第一歩が 1クラス1役割 です。
「1クラス1役割」とは何か
役割（責務）とは「そのクラスが何を担当するか」という約束
クラスは“なんでも屋”にしてはいけません。
クラスは 「私はこれだけを担当します」 と宣言する存在です。
例えば、あなたがレストランに行ったとき、
シェフが料理を作り、ウェイターが注文を取り、レジ係が会計をします。
もしシェフが料理しながら注文を取り、会計までしていたらどうでしょう。
店は回らず、ミスも増え、誰も幸せになりません。
プログラムも同じです。
1クラス1役割＝1人1仕事
これが守られると、コードは驚くほど読みやすく、壊れにくくなります。
「役割が混ざったクラス」がなぜ危険なのか
例：悪い例（全部入りクラス）
public class BadMemoApp {
// メニュー表示
// ユーザー入力
// メモの追加
// メモの削除
// メモの編集
// ファイル読み書き
// ID採番
// 日付生成
}
このクラスは 「料理・注文・会計を全部1人でやっている状態」 です。
問題点は明確です。
- どこを直せば何が変わるのか分からない
- 1つの変更が別の機能を壊す
- テストがしにくい
- コードが長くなり、読みたくなくなる
つまり 保守性が最悪 になります。
「責務を分ける」とコードはこう変わる
例：良い例（役割ごとにクラスを分ける）
ファイル保存アプリなら、役割は自然にこう分かれます。
- メモという“データ”を表すクラス
- メモをファイルに保存・読み込みするクラス
- ユーザーと会話するアプリ本体
これをコードにするとこうなります。
Memo：データを表すだけのクラス
「メモとは何か？」だけを担当する
public class Memo {
private final int id;
private final String date;
private final String body;
public Memo(int id, String date, String body) {
this.id = id;
this.date = date;
this.body = body;
}
public int getId() { return id; }
public String getDate() { return date; }
public String getBody() { return body; }
}
Memo は 「メモという概念」 だけを担当します。
ファイルのことも、ユーザー入力のことも知りません。
これが 1クラス1役割の最も美しい形 です。
MemoRepository：ファイル保存の専門家
「メモをどう保存するか？」だけを担当する
public class MemoRepository {
private final String fileName;
public MemoRepository(String fileName) {
this.fileName = fileName;
}
public void save(Memo memo) {
// ファイルに書き込む処理だけを担当
}
public List<Memo> findAll() {
// ファイルから読み込む処理だけを担当
}
}
MemoRepository は ファイル操作の専門家 です。
Memo の中身は知っていても、
「ユーザーが何をしたいか」は知りません。
App：ユーザーと会話する司会者
「アプリの流れ」を担当する
public class MemoApp {
private final MemoRepository repo;
public MemoApp(MemoRepository repo) {
this.repo = repo;
}
public void run() {
// メニュー表示
// ユーザー入力
// repo に「保存して」「読み込んで」と依頼する
}
}
App は 司会者 です。
自分では保存しません。
自分ではファイルを触りません。
自分ではメモの構造を決めません。
ただ、
「ユーザーがやりたいことを、適切な担当者に依頼する」
これだけを担当します。
1クラス1役割が生む“保守性の高さ”
変更に強くなる理由を深掘りする
1. ファイル形式を変えたくなったら？
MemoRepository だけ直せばいい。
App も Memo も一切触らなくていい。
2. メモに「タグ」を追加したくなったら？
Memo にフィールドを追加し、
MemoRepository の保存形式を変えるだけ。
App はそのまま動く。
3. 保存先をデータベースに変えたくなったら？
MemoRepository を差し替えるだけで済む。
App も Memo も変更不要。
これが 保守性の高さ＝変更に強い設計 です。
今日のまとめ：あなたが身につけた“中級者の視点”
1クラス1役割は、ただのルールではない
それは 「未来の自分を助けるための設計思想」 です。
今日のポイントをまとめると、
- クラスは“なんでも屋”にしない
- クラスは「私はこれだけを担当します」と宣言する
- 責務を分けると、コードは壊れにくくなる
- 役割が明確だと、変更が怖くなくなる
- OOP の本質は「現実世界の分業をコードに持ち込むこと」
あなたは今日、
「動くコードを書く人」から「設計できる人」へ一歩進みました。
次に進むための一歩
中級編2日目では、
「クラス同士の関係（依存・協力）」 を扱います。
