1. 概要（Overview）

Move Field は代表的なリファクタリング手法の一つです。
あるフィールドが自分のクラスではほとんど使われず、別のクラスのメソッドやロジックに強く依存している 場合、そのフィールドは「居場所を間違えている」可能性があります。

Move Field の目的は、そのフィールドを より適切なクラスへ移動させる ことで、データと振る舞いを同じ場所にまとめ、クラス間の依存を減らすことです。

2. 適用シーン（When to Use）

フィールドが所属クラスではほとんど使われない
代わりに 他クラスのメソッドから頻繁に参照されている
フィールドの存在がクラス間の不自然な依存を生んでいる

よくある匂い：

Feature Envy（機能嫉妬）
Inappropriate Intimacy（不適切な親密さ）

3. 手順（Mechanics / Steps）

フィールドの利用状況を分析し、移動先を決定（最も利用されているクラス）
移動先クラスにフィールドを新規追加
フィールドを使うメソッドを移動先クラスへ修正
互換性が必要なら元クラスに アクセサや委譲メソッド を残す
全ての呼び出しが修正できたら元のフィールドを削除

4. Kotlin 例（Before → After）

Before：フィールドが他クラスに依存

class Account(
    val customer: Customer,
    val balance: Double
)

class Customer(
    val name: String
) {
    // 本当はこの顧客に関連する情報なのに…
}

class BankService {
    fun printCustomerInfo(account: Account) {
        println("${account.customer.name} - Discount: ${account.discountRate}") 
    }
}

// ❌ discountRate が Account に置かれているが、Customer の属性に近い
var Account.discountRate: Double
    get() = 0.1
    set(value) {}

discountRate は Account にあるが、実際には Customer に属する方が自然。

After①：Customer に移動

class Account(
    val customer: Customer,
    val balance: Double
)

class Customer(
    val name: String,
    var discountRate: Double // ✅ 移動した
)

class BankService {
    fun printCustomerInfo(account: Account) {
        println("${account.customer.name} - Discount: ${account.customer.discountRate}")
    }
}

→ フィールドが 正しいクラス（Customer） に移動し、凝集度が高まった。

After②：互換性のため委譲を残す

val Account.discountRate: Double
    get() = customer.discountRate

→ 既存コードを壊さずに段階的移行が可能。

5. 効果（Benefits）

データが「本来あるべき場所」にまとまる → カプセル化強化
クラスの責務が整理される → 高凝集
不自然な依存関係が減る → 疎結合化
クラス設計がシンプルになり、保守性向上

6. 注意点（Pitfalls）

フィールドの利用状況が複雑だと、移動によって依存が逆に増える場合がある
複数クラスにまたがる性質を持つ場合は、新しいクラスを導入する ほうが適切なこともある
既存の API を公開している場合は、委譲プロパティ を残して安全に移行するのが望ましい

まとめ

Move Field は「フィールドを正しい居場所に移す」リファクタリング
判断基準：そのフィールドはどのクラスから一番使われているか？
基本思想：データを適切に配置し、クラスの責務を整理することで、可読性・保守性を高める