if-else のネストが深すぎますか?初心者でもマスターできるデザインパターンを教えます！

[[321098]]

デザインモードも使用しません。

多くの人は、ビジネス コードを書いていると考え、ロジックに従ってコードを記述し、再利用のために共通メソッドを抽出します。デザイン パターンを学ぶ必要はもちろん、使用する必要もありません。

最初は私もそう思っていましたが、彼に会うまではそう思っていました。 。 。

例えば

まず、一般的な注文インターセプト インターフェースを見てみましょう。

基本ロジック、パラメータセキュリティインターセプト、番号インターセプト、ルールインターセプトがすべて合格すると、注文の発注が許可されます。いずれかが失敗した場合は、対応する失敗理由が返されます。

多層ネストされた書き込みの場合

通常の多層ネストされたif記述法

/**
 * @著者 saier
 * @日付2020/3/31 18:03
 */
パブリッククラスOrder {
パブリックメッセージinterrupt1(){
戻る ヌル;
    }
パブリックメッセージinterrupt2(){
戻る ヌル;
    }
パブリックメッセージinterrupt3(){
戻る ヌル;
    }
パブリックメッセージinterrupt4(){
戻る ヌル;
    }
パブリックメッセージinterrupt5(){
戻る ヌル;
    } 
 
公共 静的void main(String[] args) {
注文  order = 新しいOrder ();
        if(順序.interrupt1().getResult() == 1){
            if( order.interrupt2 ().getResult() == 1){
                if(順序.interrupt3().getResult() == 1){
                    if( order.interrupt4 ().getResult() == 1){
                        if(注文.interrupt5().getResult() == 1){
                            システム。 .println ( "成功" );
                        }
                    }
                }
            }
        } 
 
    }
 } 
 
 @データ
クラスメッセージ{
    プライベートint結果;
    プライベート文字列メッセージ;
 }

例外処理ロジック

あるいは例外を使ってロジックを実行すると、コードはよりシンプルになります

/**
 * @著者 saier
 * @日付2020/3/31 18:03
 */
パブリッククラスOrder2 {
パブリックボイドinterrupt1(){ 
 
    }
パブリックボイドinterrupt2(){ 
 
    }
パブリックボイドinterrupt3(){
        //失敗
        新しい RuntimeException() をスローします。
    }
パブリックボイドinterrupt4(){
        //失敗
        新しい RuntimeException() をスローします。
    }
パブリックボイドinterrupt5(){
        //失敗
        新しい RuntimeException() をスローします。
    } 
 
公共 静的void main(String[] args) {
        Order2 order2 = 新しい Order2();
        試す{
            順序2.割り込み1();
            順序2.割り込み2();
            順序2.割り込み3();
            順序2.割り込み4();
            順序2.割り込み5();
            システム。 .println ( "成功" );
        }catch (RuntimeException e){
            システム。 .println ( "失敗" );
        } 
 
    }
 }

最初は、例外を直接使用してロジックを実行していました。しかし、その後のロジックが複雑になるにつれて、いくつかの問題が発生します。たとえば、例外は例外情報のみを返すことができ、詳細なフィールド情報を返すことはできません。

その後、Alibaba の規則では異常なロジックが禁止されていることにも気付きました。

Alibaba コード標準:

[必須] プロセス制御や条件制御には例外を使用しないでください。

注: 例外設計の本来の意図は、プログラムの動作中に発生するさまざまな予期しない状況を解決することであり、例外処理の効率は条件判断に比べてはるかに低くなります。

さらに重要なのは、コードが読みにくいことです。メソッド内で例外がスローされた場合は、コード自体の例外も考慮する必要があります。

より良い方法はなく、デザインパターンを考慮するしかありません

コードをもっと読みやすく、拡張可能にするにはどうすればいいでしょうか?

同僚のリマインダーのおかげで、突然デザインパターンを思い出しました！

私たちが達成したいこと

1. コードにはif elseのネストがあまりなく、非常に読みやすい
2. 新しいインターセプトロジックを追加するのが簡単で便利であれば、元のロジックに影響を与えず、スケーラビリティも良好です。
3. インターセプトロジックの順序は簡単に変更でき、結合度が低い

責任連鎖パターン

このシナリオでは、責任連鎖モデルが非常に適しています。 （どのようなデザインパターンをどのようなシナリオで使用するのか？これには日々の積み重ねと、さまざまなデザインパターンの基本的な使い方を知ることが必要です）

名前が示すように、責任チェーンは関連するトランザクションの責任を処理するために使用される実行チェーンです。実行チェーンには複数のノードがあり、各ノードには要求トランザクションを処理する機会（条件の一致）があります。ノードが処理を完了した場合、実際のビジネス ニーズに応じて、次のノードに渡してさらに処理したり、戻して処理を完了したりできます。

まず、フィルターの抽象クラスを作成します

パブリック抽象クラスAbstractFilter { 
 
    プライベート抽象フィルタ nextFilter; 
 
    /**
     * 責任の連鎖の次の要素
     */
パブリックvoid setNextFilter(抽象フィルター nextFilter){
        this.nextFilter = 次のフィルタ;
    } 
 
 
パブリック抽象フィルタ getLastFilter(){
        if (this.nextFilter != null ) {
 this.nextFilter.getLastFilter()を返します。
        }それ以外{
これを返します。
        }
    } 
 
パブリックvoid フィルター(FilterRequest フィルターリクエスト、Response レスポンス){
        doFilter(フィルターリクエスト、レスポンス);
        if(response.isFilterNext() && nextFilter != null ){
            次のフィルター。フィルター(フィルターリクエスト、レスポンス);
        }
    } 
 
    /**
     * 特定の傍受ロジック
     */
パブリック抽象 void doFilter(FilterRequest filterRequest、Response レスポンス); 
 
    /**
     * 傍受結果に応じた処理
     */
パブリックvoid exec (FilterRequest filterRequest, Response レスポンス){
    }
 }

フィルタ実装クラス

@成分
@注文(5)
パブリッククラス CheckParamFilter1 は AbstractFilter を拡張します {
    @オーバーライド
パブリックvoid doFilter(FilterRequest filterRequest, Response レスポンス) { 
 
    }
 } 
 
 @成分
@注文(10)
パブリッククラス CheckParamFilter2 は AbstractFilter を拡張します {
    @オーバーライド
パブリックvoid doFilter(FilterRequest filterRequest, Response レスポンス) { 
 
    }
 }

フィルターの順序を決定するには Order アノテーションを使用します。これは、後で Spring に挿入するときに驚くべき効果をもたらします。

 //Springの自動注入メカニズムを使用する
オートワイヤード
リスト<抽象フィルタ> abstractFilterList; 
 
プライベート抽象フィルタ firstFilter; 
 
 //スプリング注入後に自動的に実行される
@投稿コンストラクト
パブリックvoid 初期化チェーンフィルター(){
    // すべての呼び出しロジックを責任チェーンに挿入し、順序に従って並べ替えます。順序が小さいほど、優先順位が高くなります。
 ( int i = 0 ;i<abstractFilterList.size ( );i++){
        もし(i == 0){
            最初のフィルター = abstractFilterList.get(i);
        }それ以外{
            firstFilter.getLastFilter().setNextFilter(abstractFilterList.get(i));
        }
    }
 } 
 
 //直接使用する
パブリックレスポンスexec （）{
    firstFilter.filter(filterRequest、response);
応答を返します。
 }

デザインパターンを使用する利点

Chain of Responsibilityパターンを使用した後にどのようなメリットがあるか見てみましょう。

1. インターセプトロジックを追加するには、AbstractFilterクラスを実装するだけです。
2. インターセプト順序を変更するには、Order アノテーションのサイズを変更するだけです。サイズが小さいほど、優先度が高くなります。
3. コードは明確で、すべての処理ロジックは実装クラスに組み込まれています。

デザインパターンを使用することのデメリット

低結合と高いスケーラビリティを実現します。しかし、それはいくつかの悪い結果ももたらしました

1. ロジックはより複雑で、チェーンやその他のデータ構造を使用し、再利用できないシングルトンの問題に注意してください。
2. クラス数は劇的に増加し、クラスごとに1機の迎撃機が配備されるようになった。

最後にまとめましょう

デザインパターンはあらゆる場所に適しているわけではありません。ロジックが単純であるにもかかわらず、デザイン パターンの使用にこだわると、構造が複雑になるだけです。ビジネスシナリオに応じてご利用いただけます。

著者について: Nanshanshi: インターネット電子商取引システム開発で 7 年の経験を持つ理工系男性であり、知識共有の分野では初心者です。