一次プロジェクトコード再構築-springコンテナを用いて条件判断を乾かす

一次プロジェクトコード再構築-springコンテナを用いて条件判断を乾かす
これは、会社のプロジェクトで再構築を行う際に、複雑なビジネスで考えられるif elseを取り除く方法です.コードロジックをより明確にし、ビジネス上の結合を減らすことができます.
業務説明
私が所属しているのは保険を行うプロジェクトグループで、今回の再構築はその中の保険料計算と核保険の業務です.
プロジェクトの再構築に先立ち,保険料計算のインタフェースには,今回保険料計算を行った製品がどれであるかを判断する条件判断文が多数存在し,その製品の保険料計算方法を呼び出す.コードは大体このように見えます.

//    
String product = "123123";
if (product.equals("11111")) {
} else if (product.equals("11111")) {
    //       11111 service       
    // 
} else if (product.equals("22222")) {
    //       22222 service       
    // 
} else {
    //         
}

これらの1つの番号で判断して特定のコードを実行する方法は、新しい製品が追加されると、プロジェクトのあちこちにあります.あるいは、製品が特定の販売チャネルで特定の操作(割引など)を行うと、コードのさまざまなキーにif elesを追加し、コードの可読性とメンテナンス性に大きく影響します.コードを修正することで、他の多くの場所に影響し、奇妙なバグをもたらすことがよくあります.
だから私はこのプロジェクトを引き継いだときに再構築を考えました.再構築後,各製品間のコードを関連付けず,業務が明確で,相互に影響を及ぼさないことが望ましい.
再構築の開始
ビジネスを分析し、インタフェースを抽象化
コードを再構築する前に、私のこのプロジェクトは保険料計算をしているので、製品番号を判断するコードがたくさんありますが、最終的には同じことをしています.ここでは,保険料計算を抽象的にインタフェースとし,インタフェースに保険料計算を実行するために必要な共通の方法を定義することができる.大体こんな感じです.

/**
 *       
 *
 * @author hjx
 */
public interface PremiumCalculate {

    //    
    Result calculate(Param param);

    //             
    。。。
}

このステップは主にプロジェクトの業務を整理し、業務の同じステップを抽象化することです.
異なる製品に基づいて異なる製品の保険料計算を実現する
このステップは、上記のインタフェースを実現し、製品ごとにインタフェースを実現します.ここでは、保険料の計算を行う際に、いくつかのステップが異なる製品が多いという問題があります.各インプリメンテーションに1回書くと、大量の重複コードが発生します.
このインタフェースを実装するために抽象クラスを構築し、共有する実装コードの大部分を抽象クラスに書くことができます.このように:

/**
 *        
 */
public abstract class AbstractPremiumCalculate implements PremiumCalculate {
    /**
     *          
     * @param premiumInfo
     * @return
     */
    @Override
    public Result calculate(Param param) {
        //          
    }
}

これにより,実装クラスを新しく追加する際にこの抽象クラスを継承し,その中のいくつかの方法を書き換えるだけでよい.次のような実装クラスがたくさんあります.

PremiumCalculateP001Impl.java

PremiumCalculateP002Impl.java

PremiumCalculateP003Impl.java

PremiumCalculateP004Impl.JAvaは、保険料計算を実行するときに、異なる製品に基づいて異なる実装を呼び出すことができます.各インプリメンテーションクラスは、1つの製品のビジネスだけを書けばいいので、クラス間では相互に影響しません.新しい製品を追加するときも、新しい実装クラスを追加するだけでいいです.

でもまだ問題がある
しかし、これはまだ問題があります.ビジネスコードにif elseをたくさん書いて、今回どの実装クラスが保険料計算を実行する必要があるのかを判断するために、工場クラスを書くことができます.入力された製品番号または他のパラメータに基づいて、次のように特定の実装クラスを返します.

/**
 *          
 */
@Service
public class PremiumCalculateFactory {

    @Autowired
    @Qualifier("premiumCalculateP0001")
    private PremiumCalculate premiumCalculateP0001;

    @Autowired
    @Qualifier("premiumCalculateP0002")
    private PremiumCalculate premiumCalculateP0002;

    @Autowired
    @Qualifier("premiumCalculateP0003")
    private PremiumCalculate premiumCalculateP0003;
    
    @Autowired
    @Qualifier("premiumCalculateP0004")
    private PremiumCalculate premiumCalculateP0004;
    
    。。。。           

    public PremiumCalculate getPremiumCalculate(String productCode) {

        if (productCode.equals("P0001")) {
            return premiumCalculateP0001;
        } else if () {
           //      ，       
        }
    }

}

ファクトリクラスを追加した後,保険料計算オブジェクトを取得する際にgetPremiumCalculate()メソッドを呼び出すだけでよいので,どの実装オブジェクトを返すかをファクトリクラスに渡して処理する.保険料計算時のコードを簡単に呼び出すことができます.
やはりif elseを書いてPremiumCalculateFactoryを改造するのは避けられない.
工场类を提供した后、やはり多くの条件判断を书くことが避けられず、すべての条件判断を书いたにすぎない.この場合、製品の数が増えるにつれてif elseも増え続け、維持に苦労します.
ここでspring容器が役に立ちます.SpringにはBeanFactoryオブジェクトがあり、工場でもあり、PremiumCalculateFactoryを改造することができます.
まず,各製品に対応する保険料計算実装クラスを作成する際にspringコンテナに登録し,beanとなる.このbeanに名前を指定する必要があります.例えば、

//     bean   
@Service("PremiumCalculate:"+    )
public class PremiumCalculateP0001Impl implements PremiumCalculate {
    。。。
}

そしてPremiumCalculateFactoryを修正

/**
 *          
 */
@Service
public class PremiumCalculateFactory {
    @Autowired
    private BeanFactory beanFactory;
    
    public PremiumCalculate getPremiumCalculate(String productCode) {
        Object bean = beanFactory.getBean("PremiumCalculate:" + productCode);
        if (bean instanceof PremiumCalculate) {
            return (PremiumCalculate) bean;
        }
        throw new UnsupportedOperationException("      ：" + productCode);
    }
}

これにより,条件判断の手順を省略することができる.
結果
保険料計算と保険項目がこのように再構築された後、各製品の業務コードは相互に関連せず、製品のメンテナンスと追加時にも作業量を減らすことができ、比較的成功した.
不足
このように書くと、製品の数が増えるとjavaファイルの数も多くなるという大きな問題があります.しかし、現在の業務では製品の数に耐えられる.製品構成機能の登場により、ほとんどの製品はデータベースで構成できます.ここでは書けない部分だけなので、このパターンは可能です.
ない
https://www.cnblogs.com/hebaibai/p/11095590.html
転載先:https://www.cnblogs.com/hebaibai/p/11095590.html