j5ik2o/okite-ai

tell-dont-ask

>- 「Tell, Don't Ask」原則に基づくコードレビューと設計支援。オブジェクトの状? 外部で判断するパターンを、オブジェクトに直接命じるパターンに変換する。カプセル化を強化し、 責任をデータを持つオブジェクトに集約する設計を促進する。コードレビュー、新規実? リファクタリング時にgetterの乱用やFeature Envyの改善が? 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー:「getterを減らしたい」「カプセル化を改善して」「Feature Envyを直して」 「オブジェクトに責任を持たせたい」「デメテル…

First seen Mar 3, 2026

Installation

$ npx skills add j5ik2o/okite-ai --skill tell-dont-ask

Summary

「Tell, Don't Ask」原則に基づくコードレビューと設計支援。オブジェクトの状態を問い合わせて 外部で判断するパターンを、オブジェクトに直接命じるパターンに変換する。カプセル化を強化し、 責任をデータを持つオブジェクトに集約する設計を促進する。コードレビュー、新規実装、…

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from j5ik2o/okite-ai · top by installs.

npx skills add j5ik2o/okite-ai

Browse all from j5ik2o/okite-ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 81
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,312 B
  • docs SUMMARY.md 825 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 37 installs

SKILL.md

Tell, Don't Ask

オブジェクトに問い合わせるな、命じよ。

核心原則

オブジェクトの内部状態に基づく意思決定をし、その結果で該当オブジェクトを更新してはならない。 (『達人プログラマー 第2版』167ページ)

アプローチ 特徴 問題
Ask 状態を取得→外部で判断→操作 ロジックが散在、カプセル化破壊
Tell オブジェクトに直接命じる 責任集約、変更に強い

判断フロー

オブジェクトのメソッド呼び出し
    ↓
getterで状態を取得しているか?
    ├─ YES → その後ifで判定している?
    │         ├─ YES → Askパターン(問題あり)
    │         └─ NO → 表示/出力目的なら許容
    └─ NO → Tellパターン(推奨)

アンチパターン検出

以下のパターンを見つけたら変換を検討:

❌ if (obj.getX() > threshold) { obj.setY(...) }
❌ if (obj.getStatus() == ACTIVE) { doSomething(obj) }
❌ obj.getA().getB().doSomething()  // デメテルの法則違反
❌ for (item : list) { total += item.getPrice() }
❌ if (user.getRole() == ADMIN) { ... }

変換パターン

1. 状態判定の内部化

// ❌ Ask: 状態を取得して外部で判断
if (user.getAge() >= 18) {
    allowAccess(user);
}

// ✅ Tell: 判定ロジックをオブジェクトに持たせる
if (user.isAdult()) {
    allowAccess(user);
}

// ✅✅ さらに良い: 処理自体を委譲
user.ifAdult(() -> allowAccess());

2. 条件分岐のポリモーフィズム化

// ❌ Ask: 型で分岐
if (user.getType() == UserType.ADMIN) {
    sendAdminNotification(user);
} else {
    sendUserNotification(user);
}

// ✅ Tell: 各クラスに責任を持たせる
user.sendNotification();  // Admin/RegularUserで実装が異なる

3. コレクション操作の委譲

// ❌ Ask: 外部で集計
int total = 0;
for (Item item : order.getItems()) {
    total += item.getPrice();
}

// ✅ Tell: オブジェクトに集計を任せる
int total = order.calculateTotal();

4. Nullオブジェクトパターン

// ❌ Ask: null判定の分岐
Address addr = user.getAddress();
if (addr != null) {
    return addr.format();
} else {
    return "住所未登録";
}

// ✅ Tell: NullObjectでデフォルト動作を定義
return user.getAddress().format();  // NullAddressは"住所未登録"を返す

関連原則・スキル

原則 / スキル 関係
law-of-demeter 連鎖呼び出しを避ける(a.getB().getC()a.doC()
Feature Envy 他クラスのデータに執着 → 責任を移動
単一責任原則 データと処理を同じ場所に
カプセル化 内部状態を隠蔽し振る舞いを公開
breach-encapsulation-naming getter命名でカプセル化破壊を明示

適用指針

推奨

  • getter後にif文で判定しているコード
  • 同じ判定ロジックが複数箇所に散在
  • オブジェクトの状態を取得→更新するパターン
  • 型やステータスによる条件分岐

過剰適用を避ける

  • 表示/レポート目的のデータ取得
  • DTO/Value Objectからの単純な値取得
  • フレームワーク/ライブラリの制約がある場合
  • クラスが肥大化する場合は責任分割を検討

レビュー観点

コードレビュー時の確認ポイント:

  1. getter + if: 状態取得後に条件分岐していないか
  2. 連鎖呼び出し: a.getB().getC() のようなチェーンはないか
  3. 外部での集計: ループでデータ収集していないか
  4. 型/ステータス分岐: ポリモーフィズムで置換できないか

詳細ガイドライン

言語別の実装パターン、リファクタリング手順の詳細は [references/patterns.md](references/patterns.md) を参照。

関連スキル(併読推奨)

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

  • law-of-demeter: 構造面の補完原則(直接の友人とのみ会話する)
  • first-class-collection: コレクションへのTell, Don't Ask適用パターン
  • breach-encapsulation-naming: カプセル化を破る必要がある場合の命名規約