breach-encapsulation-naming

Breach Encapsulation Naming

getterを作るなら「カプセル化を破っている」と名前で叫べ。

核心原則

ドメインモデルのgetterには breachEncapsulationOf プレフィックスを付与し、カプセル化を破っていることを明示する。

なぜこの命名規約が必要か

ジレンマ

1. Tell Don't Ask原則: getterを使わず、オブジェクトに命じるべき
2. 現実の制約: 永続化やJSON変換ではgetterが必要
3. 問題: getterがあると、ビジネスロジックでも使ってしまう

解決策

getterを「長くて目立つ名前」にすることで：

• 使うたびに「これは例外的な使用だ」と意識させる
• コードレビューで発見しやすくなる
• 静的解析ツールで検出可能になる

命名パターン

基本形式

breachEncapsulationOf<PropertyName>()

言語別の例

// Java
public String breachEncapsulationOfName() { return this.name; }
public Money breachEncapsulationOfPrice() { return this.price; }

// Kotlin
fun breachEncapsulationOfName(): String = name
fun breachEncapsulationOfPrice(): Money = price

// TypeScript
breachEncapsulationOfName(): string { return this.name; }
breachEncapsulationOfPrice(): Money { return this.price; }

# Python
def breach_encapsulation_of_name(self) -> str:
    return self._name

// Go
func (u *User) BreachEncapsulationOfName() string { return u.name }

// Rust
pub fn breach_encapsulation_of_name(&self) -> &str { &self.name }

適用判断フロー

getterが必要か？
    ↓
├─ NO → getterを作らない（Tell Don't Ask）
│
└─ YES → 対象は？
          │
          ├─ 値オブジェクト → 通常のアクセサでOK
          │   （イミュータブルかつ振る舞いが限定的なため）
          │   例: Money.amount(), UserId.value()
          │
          └─ エンティティ → breachEncapsulationOf を使用
                            │
                            └─ なぜ必要？
                                ├─ 永続化/シリアライズ → ✅ 許容
                                ├─ 表示/UI → ✅ 許容
                                ├─ テスト → ✅ 許容
                                └─ ビジネスロジック → ❌ Tell パターンに変換

値オブジェクト vs エンティティ

理由: 値オブジェクトは内部状態が変わらないため、getterを公開しても「状態を取得→外部で判断→更新」というAskパターンが発生しにくい。

アンチパターン検出

以下のパターンを見つけたら警告：

// ❌ breachEncapsulationOf + if → Tell Don't Ask違反
if (user.breachEncapsulationOfAge() >= 18) {
    // ロジック
}

// ❌ breachEncapsulationOf + 計算 → ロジックが外部に漏れている
total = item.breachEncapsulationOfPrice() * item.breachEncapsulationOfQuantity();

// ❌ 連鎖呼び出し → デメテルの法則違反
order.breachEncapsulationOfCustomer().breachEncapsulationOfAddress().getCity();

許容される使用例

1. 永続化層（リポジトリ実装）

// ✅ 永続化のためのアクセスは許容
public UserEntity toEntity(User user) {
    return new UserEntity(
        user.breachEncapsulationOfId(),
        user.breachEncapsulationOfName(),
        user.breachEncapsulationOfEmail()
    );
}

2. JSON/XMLシリアライズ

// ✅ DTOへの変換は許容
toJson(): UserJson {
    return {
        id: this.breachEncapsulationOfId(),
        name: this.breachEncapsulationOfName()
    };
}

3. テストでのアサーション

// ✅ テストでの検証は許容
@Test
void shouldChangeName() {
    user.rename("New Name");
    assertEquals("New Name", user.breachEncapsulationOfName());
}

4. デバッグ/ログ出力

# ✅ デバッグ目的は許容
logger.debug(f"User: {user.breach_encapsulation_of_name()}")

実装ガイドライン

1. ドメインモデル側

public class User {
    private final UserId id;
    private String name;
    private Email email;

    // ❌ 通常のgetterは作らない
    // public String getName() { return name; }

    // ✅ カプセル化を破ることを明示
    public String breachEncapsulationOfName() {
        return name;
    }

    // ✅ ビジネスロジックは振る舞いとして提供
    public void rename(String newName) {
        validateName(newName);
        this.name = newName;
    }

    public boolean hasName(String name) {
        return this.name.equals(name);
    }
}

2. インフラ層での使用

// リポジトリ実装
public class JpaUserRepository implements UserRepository {
    @Override
    public void save(User user) {
        UserEntity entity = new UserEntity();
        entity.setId(user.breachEncapsulationOfId().value());
        entity.setName(user.breachEncapsulationOfName());
        entity.setEmail(user.breachEncapsulationOfEmail().value());
        jpa.save(entity);
    }
}

コードレビュー観点

静的解析との連携

カスタムリントルール例

# 検出ルール
1. breachEncapsulationOf の後に if/switch が続く → 警告
2. ドメイン層で breachEncapsulationOf を呼び出している → 警告
3. 通常の get プレフィックスがドメインモデルにある → 警告

関連スキル

参考文献

• かとじゅん「ドメインオブジェクトのためのGetter/Setter」(2018)
  • https://blog.j5ik2o.me/entry/2018/08/14/134125
  • 本スキルの原典。カプセル化の歴史的劣化とbreachEncapsulationOf命名規約の提案

詳細ガイドライン

言語別の詳細な実装パターンは references/patterns.md を参照。

関連スキル（併読推奨）

このスキルを使用する際は、以下のスキルも併せて参照すること：

• tell-dont-ask: getterを避けるべき理由の基盤原則
• law-of-demeter: getter連鎖が違反する構造面の原則
• first-class-collection: コレクションのカプセル化パターン