コードの匂いは、Java コード內(nèi)の潛在的な問題を示し、保守性、可読性、パフォーマンスに影響を與えます。 常にバグがあるわけではありませんが、バグに対処することでコードベースをクリーンで効率的に保つことができます。この記事では、5 つの一般的な Java コードの匂いを調(diào)べ、例、説明、改善された解決策を示します。

1. 長すぎるメソッド

問題: メソッドが長すぎると、可読性、テスト、メンテナンスが妨げられます。ヘルパー メソッドを使用する場合でも、複數(shù)の抽象レベルを組み合わせると単一責(zé)任原則 (SRP) に違反します。

例:

public void processOrder(Order order) {
    validateOrder(order);
    calculateDiscount(order);
    updateInventory(order);
    generateInvoice(order);
    sendNotification(order);
}

processOrder には無関係なタスク (検証、割引計算、在庫更新、請求書発行、通知) が混在しているため、意図しない結(jié)果を招くことなく変更することが困難です。

解決策: より小さく、焦點を絞ったメソッドにリファクタリングします。コマンド パターンやパイプライン パターンなどのデザイン パターンは、モジュール性を強(qiáng)化します。

リファクタリングされたコード (コマンド パターン):

interface OrderCommand { void execute(Order order); }

class ValidateOrderCommand implements OrderCommand {
    public void execute(Order order) { /* Validation logic */ }
}

// ... other commands (ApplyDiscountCommand, etc.)

class OrderProcessor {
    List<OrderCommand> commands;

    public OrderProcessor(List<OrderCommand> commands) { this.commands = commands; }

    public void processOrder(Order order) {
        for (OrderCommand command : commands) { command.execute(order); }
    }
}

// Usage
List<OrderCommand> commands = List.of(new ValidateOrderCommand(), new ApplyDiscountCommand(), ...);
OrderProcessor processor = new OrderProcessor(commands);
processor.processOrder(new Order());

利點: モジュール性の向上、獨立したテストとコマンドの再利用、新しいステップの簡単な追加。

2. 神クラス

問題: 「神クラス」はあまりにも多くの責(zé)任を処理するため、結(jié)合度が高く、保守性が低下します。

例:

public class OrderManager {
    public void createOrder() { /* Implementation */ }
    public void updateOrder() { /* Implementation */ }
    public void deleteOrder() { /* Implementation */ }
    public void validatePayment() { /* Implementation */ }
    public void sendInvoice() { /* Implementation */ }
}

解決策: 責(zé)任をより小規(guī)模で集中的なクラスに分割します。

リファクタリングされたコード:

public class OrderService {
    public void createOrder() { /* Implementation */ }
    // ... other order-related methods
}

public class PaymentService {
    public void validatePayment() { /* Implementation */ }
}

public class NotificationService {
    public void sendInvoice() { /* Implementation */ }
}

利點: 結(jié)合の減少、モジュール性の向上、メンテナンス、テストの容易化、獨立した拡張。

3. マジックナンバー

問題: リテラル數(shù)値を直接使用すると、コードの明瞭さが低下し、変更の危険が生じます。

例:

public double calculateDiscount(double totalAmount) {
    return totalAmount > 1000 ? totalAmount * 0.1 : totalAmount;
}

解決策: リテラル數(shù)値を名前付き定數(shù)に置き換えます。

リファクタリングされたコード:

private static final double DISCOUNT_THRESHOLD = 1000;
private static final double DISCOUNT_RATE = 0.1;

public double calculateDiscount(double totalAmount) {
    return totalAmount > DISCOUNT_THRESHOLD ? totalAmount * DISCOUNT_RATE : totalAmount;
}

利點: 可読性の向上、更新中のエラーのリスクの軽減、ビジネス ロジックの明確化。

4. コードが重複しています

問題: メソッドまたはクラス間でコードを繰り返すと、不整合が発生し、メンテナンスの悩みが生じます。

例:

public double calculateTax(double amount) { return amount * 0.18; }
public double calculateDiscount(double amount) { return amount * 0.1; }

解決策: 共通ロジックを再利用可能なメソッドに抽象化します。

リファクタリングされたコード:

private double applyRate(double amount, double rate) { return amount * rate; }

public double calculateTax(double amount) { return applyRate(amount, 0.18); }
public double calculateDiscount(double amount) { return applyRate(amount, 0.1); }

利點: 冗長性を排除し、一貫性を確保し、変更と拡張を簡素化します。

5. 過剰なパラメータリスト

問題: 多くのパラメータを持つメソッドは読みにくく、理解しにくく、呼び出し中にエラーが発生しやすくなります。

例:

public void processOrder(Order order) {
    validateOrder(order);
    calculateDiscount(order);
    updateInventory(order);
    generateInvoice(order);
    sendNotification(order);
}

解決策: パラメータをオブジェクト內(nèi)にカプセル化するか、ビルダー パターンを使用します。

リファクタリングされたコード:

interface OrderCommand { void execute(Order order); }

class ValidateOrderCommand implements OrderCommand {
    public void execute(Order order) { /* Validation logic */ }
}

// ... other commands (ApplyDiscountCommand, etc.)

class OrderProcessor {
    List<OrderCommand> commands;

    public OrderProcessor(List<OrderCommand> commands) { this.commands = commands; }

    public void processOrder(Order order) {
        for (OrderCommand command : commands) { command.execute(order); }
    }
}

// Usage
List<OrderCommand> commands = List.of(new ValidateOrderCommand(), new ApplyDiscountCommand(), ...);
OrderProcessor processor = new OrderProcessor(commands);
processor.processOrder(new Order());

利點: 可読性と拡張性が向上します。パラメータを追加する場合、メソッド シグネチャを変更する必要はありません。

コードの臭いに積極的に対処すると、より大きな設(shè)計上の問題が防止され、技術(shù)的負(fù)債が軽減され、より堅牢で保守しやすい Java アプリケーションが実現(xiàn)されます。 よりクリーンで効率的なコードを作成するには、DRY (Don't Reply Yourself) と SRP (Single Responsibility Principle) の原則を覚えておいてください。

以上がJava のよくあるコードの臭いとその修正方法の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。