13日目のゴールとテーマ
13日目のテーマは
「プロジェクトを“整理する力”と“ライブラリを使う力”を身につける」 です。
ここまでで、あなたは
クラス
オブジェクト
カプセル化
クラス同士の関係
例外処理
ファイル保存
を使って、タスク管理アプリをここまで育ててきました。
今日はそこから一歩引いて、
コードを“整理する”という視点
標準ライブラリを“うまく借りる”という視点
を加えていきます。
いまのプロジェクト構成を見直す
1ファイルに詰め込みすぎていないか
ここまでの流れで、あなたのプロジェクトには、だいたいこんなクラスがあるはずです。
Main
Task
TaskManager
InputHelper
これらを全部「デフォルトパッケージ」(package 行なし)に置いていると、
ファイル数が増えるにつれて、どこに何があるか分かりにくくなってきます。
現場の Java では、
クラスを「パッケージ」という単位でグループ分けします。
com.example.todoapp.todo
のような名前を付けて、
「このパッケージにはタスクアプリ関連のクラスが入っている」
と意味づけしていきます。
パッケージという“フォルダ”の考え方
物理的なフォルダと論理的な名前
パッケージは、ざっくり言うと
ソースコード上の「名前のフォルダ」
ファイルシステム上の「物理フォルダ」とも対応する
というものです。
例えば、app.todo というパッケージを作るとします。
Task.java の先頭に、こう書きます。
package app.todo;
public class Task {
// 中身は同じ
}
JavaTaskManager も同じようにします。
package app.todo;
public class TaskManager {
// 中身は同じ
}
JavaMain も同じパッケージにするなら、こうです。
package app.todo;
public class Main {
// 中身は同じ
}
Javaこれで、「この3つは app.todo というグループに属している」という意味になります。
IDE を使っている場合、app/todo というフォルダが自動的に作られ、
その中に .java ファイルが置かれる形になります。
パッケージを分ける意味
名前の衝突を防ぐ・役割ごとに整理する
パッケージを使う意味は、単に「フォルダ分け」だけではありません。
同じ名前のクラスがあっても、
パッケージが違えば共存できます。
app.todo.Taskapp.shop.Task
のように、
「タスク」という概念が別の文脈で出てきても、
パッケージで区別できます。
また、役割ごとにパッケージを分けることもあります。
app.todo(アプリ本体)app.util(汎用的なユーティリティ)
などです。
例えば InputHelper は、
「タスクアプリ専用」というより「汎用的な入力補助」です。
なので、こういう整理もできます。
package app.util;
public class InputHelper {
// readInt など
}
Javaそして Main 側では、こうインポートします。
package app.todo;
import app.util.InputHelper;
public class Main {
// 中身
}
Javaこうやって、「どのクラスがどのグループに属しているか」を
パッケージで表現できるようになると、
プロジェクト全体の見通しがよくなります。
標準ライブラリを“味方にする”感覚
「自分で全部書かない」のがプロの発想
ここまでのコードでも、すでに標準ライブラリを使っていました。
ArrayList
Scanner
FileReader / FileWriter
BufferedReader / BufferedWriter
InputMismatchException
IOException
これらはすべて「Javaが最初から用意してくれているクラス」です。
現場のプログラミングでは、
「まず標準ライブラリにないか探す」
「なければ自分で書く」
という順番で考えます。
例えば、
「日付と時刻を扱いたい」となったら、java.time パッケージを使います。
例題:締め切り付きタスクにしてみる
日付・時刻ライブラリを軽く触ってみる
標準ライブラリの力を感じるために、
Task に「締め切り日」を足すイメージを見てみましょう。
本格的にやると少し難しいので、
今日は「こんな感じで使うんだな」という雰囲気をつかむのが目的です。
Java 8 以降では、java.time.LocalDate というクラスで日付を扱えます。
Task にフィールドを足すとしたら、こんな感じです。
import java.time.LocalDate;
public class Task {
private String title;
private boolean done;
private int priority;
private LocalDate dueDate; // 締め切り日
public Task(String title, int priority, LocalDate dueDate) {
setTitle(title);
setPriority(priority);
this.done = false;
this.dueDate = dueDate;
}
public LocalDate getDueDate() {
return this.dueDate;
}
public void setDueDate(LocalDate dueDate) {
this.dueDate = dueDate;
}
public void printWithNumber(int number) {
String status = done ? "完了" : "未完了";
String priorityLabel = toPriorityLabel(priority);
String due = (dueDate != null) ? dueDate.toString() : "未設定";
System.out.println(number + ": " + title + " / 状態: " + status
+ " / 優先度: " + priorityLabel + " / 締め切り: " + due);
}
// 他のメソッドは省略
}
Javaここでのポイントは、
日付を「ただの文字列」ではなく LocalDate で持っている
→ 「日付としての意味」を保ったまま扱える
dueDate.toString() で "2026-04-06" のような形式で表示できる
というところです。
Main 側で日付を入力させるとしたら、
本当は "2026-04-06" のような文字列を LocalDate.parse で変換します。
import java.time.LocalDate;
import java.time.format.DateTimeParseException;
// 入力例(イメージ)
System.out.print("締め切り日を入力してください(例: 2026-04-06、空なら未設定): ");
String dateText = scanner.nextLine();
LocalDate dueDate = null;
if (!dateText.isEmpty()) {
try {
dueDate = LocalDate.parse(dateText);
} catch (DateTimeParseException e) {
System.out.println("日付の形式が正しくありません。締め切りは未設定にします。");
}
}
Javaここでも、
「日付のパースに失敗したらどうするか」を
例外処理で決めています。
この例は「実装しきる」ことよりも、
「標準ライブラリを使うと、日付のような面倒なものも扱える」
という感覚を持つためのものです。
「自分のクラス」と「ライブラリのクラス」の境界
どこまで自分で作り、どこから借りるか
Task や TaskManager は、
あなたが「アプリの世界」を表現するために作ったクラスです。
一方、ArrayList や LocalDate は、
「汎用的な便利道具」として Java が用意しているクラスです。
この2つの役割は、はっきり分かれています。
アプリ固有の概念
→ 自分でクラスを作る(Task, TaskManager など)
汎用的な処理(リスト、日付、ファイル、文字列操作など)
→ 標準ライブラリを使う
この境界を意識できるようになると、
「ここは自分でクラスを作るべきだな」
「ここはライブラリを使えば一瞬だな」
という判断ができるようになります。
13日目の小さなリファクタリング
「名前」と「責任」をもう一度見直す
ここまで来たあなたなら、
もう「コードを書くだけ」から一歩進んで、
「コードを育てる」ことができます。
例えば、TaskManager の中を見てみてください。
タスク追加
一覧表示
絞り込み表示
完了処理
削除
保存・読み込み
いろいろな責任が集まっています。
今はまだこのままで構いませんが、
将来的には、
保存・読み込みだけ別クラスに切り出す(TaskStorage など)
表示ロジックを別クラスに分ける
といった分割も考えられます。
大事なのは、
「このクラスは何の責任を持っているのか?」
「名前と中身がちゃんと対応しているか?」
を意識してコードを見る癖です。
13日目で一番大事な感覚
「コードは“積み上げる”だけじゃなく、“整理していく”もの」
今日あなたに持ってほしい感覚はこれです。
プログラミングは、
新しいコードを足していくだけの作業ではありません。
増えてきたコードを整理する
役割ごとに分ける
名前を見直す
標準ライブラリに任せられるところは任せる
こうやって、
「プロジェクト全体の形」を整えていく作業でもあります。
パッケージでグループ分けする
標準ライブラリを味方につける
自分のクラスとライブラリのクラスの境界を意識する
このあたりの感覚が芽生えてきたら、
もう“初心者のその先”に足を踏み入れています。
13日目のまとめと、14日目への予告
今日やったことを短く整理すると、
パッケージでクラスをグループ分けするイメージを持った
InputHelper のような「汎用クラス」を別パッケージに置く発想を見た
標準ライブラリ(特に java.time)の存在と使い方の雰囲気をつかんだ
「自分で作るクラス」と「借りてくるクラス」の役割の違いを意識した
コードを“整理する”“育てる”という視点を持った
14日目は、この2週間の総仕上げとして、
ここまで作ってきたタスクアプリを振り返りながら、
「自分は何ができるようになったのか」
「この先、どう広げていけるのか」
を整理していきます。
単なる「文法の勉強」ではなく、
「アプリを作れる自分」になったことを、
ちゃんと言葉にして確認していきましょう。
