Javaで本格的な開発に携わるようになると、「クラスの設計」が避けては通れないテーマになります。本記事では、中級者が実務でつまずきやすい「Javaクラス設計の基本」を、設計思想や具体例とともに解説します。
📘 元記事(ブログ)はこちら
https://atnettec.com/2025/07/19/what-are-java-classes/
この記事でわかること
クラス設計における基本的な考え方(単一責任・カプセル化・継承の使い所)
実務でよくある「悪いクラス設計」のパターンと改善方法
設計の具体例(Userクラスを例にした良い設計 vs 悪い設計)
クラスとは「責任の単位」
Javaにおけるクラスは、「データ(フィールド)」と「処理(メソッド)」をひとまとめにした構造です。
public class User {
private String name;
private int age;
public void introduce() {
System.out.println("名前:" + name + "、年齢:" + age);
}
}
ここで重要なのは、クラスは「何をするためのものか」が明確であるべきということ。
責任の範囲が広すぎたり、複数の目的を持っていたりすると、保守性が一気に落ちます。
よくある「悪いクラス設計」例
以下は初心者〜中級者がやりがちな、責務が分散された悪い例です。
public class User {
private String name;
private int age;
public void introduce() {
System.out.println("名前:" + name + "、年齢:" + age);
}
public void saveToDatabase() {
// データベース処理(責務過多!)
}
public void sendEmail() {
// メール送信処理(責務過多!)
}
}
👎 問題点
Userクラスが「表示・保存・通知」など複数の責務を持っている
単体テストがしにくくなる
将来的な変更で副作用が起こりやすい
✅ 改善例:クラスごとに責任を分ける
public class User {
private String name;
private int age;
public String getName() { return name; }
public int getAge() { return age; }
}
public class UserRepository {
public void save(User user) {
// DB保存処理
}
}
public class UserNotifier {
public void sendWelcomeEmail(User user) {
// メール送信処理
}
}
👍 改善ポイント
Userはあくまでデータと基本的なロジックだけを持つ
永続化処理(Repository)や通知処理(Notifier)は別のクラスへ分離
単一責任の原則(SRP)を守っている
クラス設計の3原則(SOLIDの一部)
実務で意識すべき3つの基本原則を紹介します。
原則 | 内容 |
---|---|
SRP(単一責任原則) | 1クラスに1つの責任だけを持たせる |
OCP(開放閉鎖原則) | 拡張に開かれ、修正に閉じている |
LSP(リスコフの置換原則) | サブクラスは親クラスの置き換えとして使えるべき |
💡 設計時に考えるべきチェックリスト
✅ クラスの名前で「何をするクラスか」が伝わるか?
✅ 1つのクラスに複数の役割が詰め込まれていないか?
✅ クラス同士の依存関係はシンプルか?
📌 補足:継承とインターフェースの使い分け
特徴 | 継承(extends) | インターフェース(implements) |
---|---|---|
用途 | 親クラスの機能を再利用 | 共通の振る舞いの定義 |
制約 | 単一継承のみ | 複数実装が可能 |
柔軟性 | 低い(密結合) | 高い(疎結合) |
実務では「インターフェース+DI」が推奨されます。
🧑💻 実務でのワンポイント
実際の現場では、「設計と実装はセット」 で考える必要があります。
設計図だけで完璧な構造を作るのは難しいので、まずは分かりやすく小さく作る→リファクタリングが基本です。
設計に悩んだら「このクラスの責任は何か?」を自問してみてください。
まとめ
クラスは「単一責任」であることが設計の基本
永続化・通知などの処理は別クラスへ分離する
SOLID原則を意識することで、変更に強くテストしやすいコードになる
🔗 関連記事
Javaの例外処理とは?try-catch構文を使いこなすテクニックまとめ