第 9 章: SOLID 原則とモジュール設計¶
9.1 はじめに¶
前章までで、FizzBuzz のコードはデザインパターンを適用して大きく改善されました。しかし、すべてのクラスが tdd.fizzbuzz という 1 つのパッケージに詰め込まれています。
この章では、SOLID 原則 を確認しながら、クラスを適切なパッケージに分割する モジュール設計 を行います。
9.2 SOLID 原則の確認¶
FizzBuzz のコードが SOLID 原則にどの程度準拠しているか確認しましょう。
単一責任原則（SRP: Single Responsibility Principle）¶
クラスを変更する理由は 1 つだけであるべき。
| クラス | 責務 | 変更理由 | SRP 準拠 |
|---|---|---|---|
FizzBuzzType01 |
タイプ 1 の変換ルール | タイプ 1 のルール変更時 | OK |
FizzBuzzType02 |
タイプ 2 の変換ルール | タイプ 2 のルール変更時 | OK |
FizzBuzzType03 |
タイプ 3 の変換ルール | タイプ 3 のルール変更時 | OK |
FizzBuzzValue |
値の保持と等価性 | 値の表現が変わるとき | OK |
FizzBuzzList |
コレクション操作 | コレクション操作が変わるとき | OK |
FizzBuzzValueCommand |
単一値変換の実行 | 実行方法が変わるとき | OK |
FizzBuzzListCommand |
リスト生成の実行 | 実行方法が変わるとき | OK |
ポリモーフィズムとデザインパターンの適用により、各クラスが単一の責務を持つようになっています。
開放閉鎖原則（OCP: Open-Closed Principle）¶
拡張に対して開いていて、修正に対して閉じているべき。
新しいタイプ（例: タイプ 4）を追加する場合を考えてみましょう。
// タイプ 4 を追加するのに必要な変更
// 1. 新しいクラスを追加（既存コードの修正なし）
public class FizzBuzzType04 extends FizzBuzzType {
@Override
public FizzBuzzValue generate(int number) {
// タイプ 4 のルール
return new FizzBuzzValue(number, String.valueOf(number));
}
}
// 2. ファクトリメソッドに 1 行追加（最小限の修正）
case 4: return new FizzBuzzType04();
FizzBuzzType 階層は拡張に対して開いています。新しいタイプを追加しても、既存のタイプクラスや FizzBuzzCommand を修正する必要はありません。
依存性逆転原則（DIP: Dependency Inversion Principle）¶
上位モジュールは下位モジュールに依存すべきではない。どちらも抽象に依存すべき。
FizzBuzz → FizzBuzzType（抽象）← FizzBuzzType01, 02, 03
FizzBuzzCommand（抽象）← FizzBuzzValueCommand, FizzBuzzListCommand
FizzBuzz クラスは具体的な FizzBuzzType01 ではなく、抽象的な FizzBuzzType に依存しています。
9.3 パッケージ設計¶
現在の問題¶
すべてのクラスが tdd.fizzbuzz に入っています。
tdd.fizzbuzz/
├── FizzBuzz.java
├── FizzBuzzType.java
├── FizzBuzzType01.java
├── FizzBuzzType02.java
├── FizzBuzzType03.java
├── FizzBuzzValue.java
├── FizzBuzzList.java
├── FizzBuzzCommand.java
├── FizzBuzzValueCommand.java
├── FizzBuzzListCommand.java
└── Main.java
クラスが増えるにつれて、どのクラスがどの責務を持つかが分かりにくくなります。
パッケージ分割¶
責務に基づいてパッケージを分割します。
tdd/
├── App.java # エントリポイント
└── fizzbuzz/
├── domain/
│ ├── type/
│ │ ├── FizzBuzzType.java # 抽象タイプ + Factory
│ │ ├── FizzBuzzType01.java # タイプ 1
│ │ ├── FizzBuzzType02.java # タイプ 2
│ │ └── FizzBuzzType03.java # タイプ 3
│ └── model/
│ ├── FizzBuzzValue.java # 値オブジェクト
│ └── FizzBuzzList.java # コレクション
└── application/
├── FizzBuzzCommand.java # コマンドインターフェース
├── FizzBuzzValueCommand.java # 単一値コマンド
└── FizzBuzzListCommand.java # リストコマンド
パッケージの責務¶
| パッケージ | 責務 | 含まれるクラス |
|---|---|---|
tdd.fizzbuzz.domain.type |
変換ルール（ビジネスロジック） | FizzBuzzType 階層 |
tdd.fizzbuzz.domain.model |
ドメインモデル（値・コレクション） | FizzBuzzValue, FizzBuzzList |
tdd.fizzbuzz.application |
アプリケーション層（操作の実行） | FizzBuzzCommand 階層 |
依存関係¶
application パッケージは domain に依存しますが、domain は application に依存しません。これにより、ビジネスロジックがアプリケーション層から独立して変更・テストできます。
9.4 エントリポイントの更新¶
パッケージ分割後の App.java です。
package tdd;
import tdd.fizzbuzz.application.FizzBuzzListCommand;
import tdd.fizzbuzz.application.FizzBuzzValueCommand;
import tdd.fizzbuzz.domain.model.FizzBuzzList;
import tdd.fizzbuzz.domain.model.FizzBuzzValue;
import tdd.fizzbuzz.domain.type.FizzBuzzType;
public class App {
private static final int MAX_NUMBER = 100;
public static void main(String[] args) {
FizzBuzzType type = FizzBuzzType.create(1);
// 単一値の取得
FizzBuzzValueCommand valueCommand
= new FizzBuzzValueCommand(type);
FizzBuzzValue value = valueCommand.execute(15);
System.out.println(value);
// リストの生成
FizzBuzzListCommand listCommand
= new FizzBuzzListCommand(type);
FizzBuzzList list = listCommand.executeList(MAX_NUMBER);
for (FizzBuzzValue item : list.getValues()) {
System.out.println(item.getValue());
}
}
}
9.5 テストの更新¶
テストもパッケージ構造に合わせて再配置します。
src/test/java/tdd/fizzbuzz/
├── domain/
│ ├── type/
│ │ └── FizzBuzzTypeTest.java # タイプ別テスト
│ └── model/
│ ├── FizzBuzzValueTest.java # 値オブジェクトテスト
│ └── FizzBuzzListTest.java # コレクションテスト
└── application/
└── FizzBuzzCommandTest.java # コマンドテスト
FizzBuzzTypeTest（タイプ別テスト）¶
package tdd.fizzbuzz.domain.type;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
class FizzBuzzTypeTest {
@Nested
class タイプ1の場合 {
private final FizzBuzzType type = FizzBuzzType.create(1);
@Test
void 三と五の倍数でFizzBuzzを返す() {
assertEquals("FizzBuzz", type.generate(15).getValue());
}
@Test
void 三の倍数でFizzを返す() {
assertEquals("Fizz", type.generate(3).getValue());
}
@Test
void 五の倍数でBuzzを返す() {
assertEquals("Buzz", type.generate(5).getValue());
}
@Test
void その他は数値を返す() {
assertEquals("1", type.generate(1).getValue());
}
}
@Nested
class タイプ2の場合 {
private final FizzBuzzType type = FizzBuzzType.create(2);
@Test
void 常に数値を返す() {
assertEquals("3", type.generate(3).getValue());
assertEquals("5", type.generate(5).getValue());
assertEquals("15", type.generate(15).getValue());
}
}
@Nested
class タイプ3の場合 {
private final FizzBuzzType type = FizzBuzzType.create(3);
@Test
void 十五の倍数のみFizzBuzzを返す() {
assertEquals("FizzBuzz", type.generate(15).getValue());
assertEquals("3", type.generate(3).getValue());
assertEquals("5", type.generate(5).getValue());
}
}
@Nested
class 不正なタイプの場合 {
@Test
void 例外をスローする() {
assertThrows(IllegalArgumentException.class,
() -> FizzBuzzType.create(4));
}
}
}
9.6 まとめ¶
この章では SOLID 原則を確認しながらモジュール設計を行いました。
| 概念 | 適用 |
|---|---|
| 単一責任原則（SRP） | 各クラスが 1 つの責務を持つ |
| 開放閉鎖原則（OCP） | 新タイプ追加で既存コード変更不要 |
| 依存性逆転原則（DIP） | 抽象への依存で結合度を低減 |
| パッケージ分割 | domain（ビジネスロジック）と application（操作）の分離 |
第 3 部の振り返り¶
第 3 部（第 7〜9 章）を通じて、手続き的な FizzBuzz をオブジェクト指向設計に変換しました。
| 章 | テーマ | 学んだこと |
|---|---|---|
| 7 | カプセル化とポリモーフィズム | private / final、Strategy パターン、抽象クラス |
| 8 | デザインパターンの適用 | Value Object、First-Class Collection、Command、Factory Method |
| 9 | SOLID 原則とモジュール設計 | SRP / OCP / DIP、パッケージ分割、ドメインモデル |
Before: 1 つのクラスに全ロジック（手続き型）
After: 責務ごとにパッケージ分割された OOP 設計
次の第 4 部では、Java の関数型プログラミング機能（Stream API、Optional、Lambda）を使って、さらにコードを発展させます。