プログラミングの「機能羨望」に陥らない開発方針

みなさん、コードを書いていて「このクラスが別のクラスのメソッドを頻繁に呼び出している」「なんだか責任の所在が曖昧」と感じたことはありませんか？

「機能が複雑になって、どこに何の処理があるのか分からない」「修正するたびに他の部分も変更が必要」という状況に陥っていませんか？

実は、これらの問題は「機能羨望（Feature Envy）」と呼ばれるコードの悪臭の典型例です。機能羨望を理解し、適切に対処することで、保守性が高く理解しやすいコードが書けるようになります。

この記事では、機能羨望の概念から具体的な対処法まで、実践的な開発方針を詳しく解説します。

機能羨望（Feature Envy）とは

基本的な概念

機能羨望とは、オブジェクト指向プログラミングにおける「コードの悪臭」の一つで、あるクラスが他のクラスの機能やデータに過度に依存している状態を指します。

機能羨望の特徴

• 一つのメソッドが他のオブジェクトのメソッドを頻繁に呼び出す
• 自分のクラスよりも他のクラスのデータを多く使用する
• 責任の所在が曖昧になる
• 結合度が高く、変更に弱い構造

具体例で理解する

問題のあるコード例

// 機能羨望の例
public class Order {
    private Customer customer;
    private Product product;
    
    public double calculateTotalPrice() {
        // 他のオブジェクトのデータばかり使用
        double basePrice = product.getPrice();
        double discount = customer.getDiscountRate();
        double tax = product.getTaxRate();
        
        return basePrice * (1 - discount) * (1 + tax);
    }
}

この例では、OrderクラスがCustomerとProductのデータを直接操作しており、機能羨望の状態になっています。

改善されたコード例

// 機能羨望を解決したコード
public class Order {
    private Customer customer;
    private Product product;
    
    public double calculateTotalPrice() {
        // 各オブジェクトに責任を委譲
        double basePrice = product.calculatePrice();
        double discountedPrice = customer.applyDiscount(basePrice);
        
        return discountedPrice;
    }
}

public class Product {
    private double price;
    private double taxRate;
    
    public double calculatePrice() {
        return price * (1 + taxRate);
    }
}

public class Customer {
    private double discountRate;
    
    public double applyDiscount(double price) {
        return price * (1 - discountRate);
    }
}

機能羨望が発生する原因

設計上の問題

責任の分散不足

• 一つのクラスが多くの責任を持ちすぎる
• 適切な抽象化ができていない
• データとロジックの配置が不適切

オブジェクト指向の理解不足

• カプセル化の原則を無視
• 「Tell, Don't Ask」原則の軽視
• 継承と委譲の使い分けができていない

開発プロセスの問題

段階的な機能追加

• 初期設計時の責任分担が不明確
• 機能追加のたびに既存クラスを修正
• リファクタリングの機会を逃す

チーム間の認識不足

• 設計原則の共有不足
• コードレビューの観点が不適切
• 技術的負債の蓄積

機能羨望を回避する設計原則

単一責任の原則（SRP）

クラスの責任を明確化

一つのクラスは一つの責任のみを持つべきです。

// 悪い例：複数の責任を持つクラス
public class User {
    private String name;
    private String email;
    
    // ユーザー情報の管理
    public void updateProfile() { /* ... */ }
    
    // メール送信（別の責任）
    public void sendNotification() { /* ... */ }
    
    // データベース操作（別の責任）
    public void saveToDatabase() { /* ... */ }
}

// 良い例：責任を分離
public class User {
    private String name;
    private String email;
    
    public void updateProfile() { /* ... */ }
}

public class EmailService {
    public void sendNotification(User user) { /* ... */ }
}

public class UserRepository {
    public void save(User user) { /* ... */ }
}

Tell, Don't Ask原則

データではなく、行動を要求

オブジェクトの内部状態を直接取得するのではなく、オブジェクトに行動を要求します。

// 悪い例：Ask（データを聞く）
if (user.getAge() >= 18) {
    user.setCanVote(true);
}

// 良い例：Tell（行動を要求）
user.checkVotingEligibility();

デメテルの法則

最小限の知識の原則

オブジェクトは直接の友人とのみ会話すべきです。

// 悪い例：連鎖的な呼び出し
customer.getAddress().getCity().getName();

// 良い例：委譲による隠蔽
customer.getCityName();

機能羨望の検出方法

静的解析ツールの活用

代表的なツール

• SonarQube: 総合的なコード品質分析
• PMD: Java向けコード解析
• ESLint: JavaScript向けコード解析
• RuboCop: Ruby向けコード解析

これらのツールは機能羨望を自動的に検出できます。

手動でのチェックポイント

コードレビュー時の観点

## 機能羨望チェックリスト

### メソッドレベル
- 他のオブジェクトのメソッドを3回以上呼び出している
- 自分のクラスのデータよりも他のクラスのデータを多く使用
- メソッドの処理が他のクラスに依存している

### クラスレベル
- 他のクラスのpublicメソッドを頻繁に呼び出している
- 内部データよりも外部データを多く参照している
- 変更時に他のクラスも同時に修正が必要

メトリクスによる測定

結合度の測定

• CBO (Coupling Between Objects): クラス間の結合度
• DIT (Depth of Inheritance Tree): 継承階層の深さ
• RFC (Response For a Class): クラスの応答性

これらの指標により、機能羨望の兆候を数値で把握できます。

機能羨望を解決するリファクタリング手法

メソッドの移動（Move Method）

最も基本的な解決策

機能羨望を起こしているメソッドを、より適切なクラスに移動します。

// リファクタリング前
public class Account {
    private AccountType type;
    
    public double calculateInterest() {
        // AccountTypeのデータを頻繁に使用
        if (type.isPremium()) {
            return balance * type.getPremiumRate();
        } else {
            return balance * type.getStandardRate();
        }
    }
}

// リファクタリング後
public class Account {
    private AccountType type;
    
    public double calculateInterest() {
        return type.calculateInterest(balance);
    }
}

public class AccountType {
    public double calculateInterest(double balance) {
        if (isPremium()) {
            return balance * getPremiumRate();
        } else {
            return balance * getStandardRate();
        }
    }
}

データの移動（Move Field）

データと処理を同じ場所に

頻繁に使用されるデータを、それを使用するクラスに移動します。

クラスの抽出（Extract Class）

責任の分離

一つのクラスが持つ複数の責任を、別々のクラスに分離します。

// リファクタリング前
public class Employee {
    private String name;
    private String officePhone;
    private String personalPhone;
    
    public String getOfficePhone() { return officePhone; }
    public String getPersonalPhone() { return personalPhone; }
}

// リファクタリング後
public class Employee {
    private String name;
    private ContactInfo contactInfo;
    
    public String getOfficePhone() { 
        return contactInfo.getOfficePhone(); 
    }
}

public class ContactInfo {
    private String officePhone;
    private String personalPhone;
    
    public String getOfficePhone() { return officePhone; }
    public String getPersonalPhone() { return personalPhone; }
}

予防的な開発方針

設計段階での対策

ドメイン駆動設計（DDD）

ビジネスロジックを適切なドメインオブジェクトに配置します。

// DDDを適用した設計
public class Order {
    private OrderId id;
    private CustomerId customerId;
    private List<OrderLine> orderLines;
    
    public Money calculateTotal() {
        return orderLines.stream()
            .map(OrderLine::calculateSubtotal)
            .reduce(Money.ZERO, Money::add);
    }
}

public class OrderLine {
    private Product product;
    private Quantity quantity;
    
    public Money calculateSubtotal() {
        return product.getPrice().multiply(quantity.getValue());
    }
}

開発プロセスでの対策

継続的リファクタリング

• 機能追加のたびにコード構造を見直す
• 定期的なコードレビューの実施
• 技術的負債の早期返済

テスト駆動開発（TDD）

• 適切な責任分担を意識した設計
• リファクタリングを安全に実行
• 継続的な品質改善

実践的なガイドライン

日常的な注意点

コーディング時の心がけ

• メソッドを書く前に「この処理はどのクラスの責任か？」を考える
• 他のオブジェクトのデータを直接操作しない
• 「なぜこのメソッドがここにあるのか？」を常に問う

チーム開発での取り組み

• 設計原則の共有
• コードレビューでの機能羨望チェック
• 定期的なリファクタリング時間の確保

段階的な改善プロセス

ステップ1: 現状把握

• 機能羨望の発生箇所を特定
• 影響範囲の分析
• 優先度の設定

ステップ2: 段階的リファクタリング

• 小さな変更から開始
• テストによる動作確認
• 継続的な改善

ステップ3: 予防策の実装

• 設計ガイドラインの策定
• 自動化ツールの導入
• チーム教育の実施

まとめ

機能羨望を回避することで、保守性が高く理解しやすいコードを書くことができます。

重要なポイント

• 適切な責任分担の設計
• Tell, Don't Ask原則の実践
• 継続的なリファクタリング
• チーム全体での意識共有

実践のメリット

• コードの可読性向上
• 保守コストの削減
• バグの発生率低下
• 開発速度の向上

機能羨望を意識した開発により、長期的に価値のあるソフトウェアを構築できます。

まずは現在のコードで機能羨望が発生していないかチェックし、見つかった場合は適切なリファクタリングを実施してみてください。継続的な改善により、必ず品質の高いコードが書けるようになります。