この記事では、責任連鎖デザイン パターンを使用した背景と経験を紹介します。これにより、読者はこのデザイン パターンに対する印象を深め、現在関与し、責任を負っているプロジェクトを「刷新」し、それによってシステムの改善を図ることができます。システムの「フェイスリフト」。自分の仕事のあらゆる詳細を共有します。
1. 背景
私が担当しているシステムには、パーティションモジュールというモジュールがあります。この言葉を直接見ると、多くの人が混乱したり誤解したりすると思います。実際、その本当の意味は「ルーティング」です。 「ルーティング」とは何かについて簡単に説明します。
誰もがオンラインショッピングの経験があると思いますが、注文を行うと、いつでもどこでも注文の物流追跡状況を確認できます。 B. ルーティングライン。たとえば、注文 order1 は A から目的地 F に輸送する必要があります。A->B->D->F の順に移動することも、A->D->F の順に移動することもできます。選択されるかどうかは、システムに設定されているルートと、対応する一致ルールがフィルターで除外されるかどうかによって異なります。
長い間、システム内のルーティング構成とルールは静的でした (いわゆる静的とは、事前に構成され、ほぼ固定されていることを意味します)。このアプローチの欠点は明らかです。つまり、コストがかかりません。前述の例では、明らかに輸送ルートが削減されたり、直接配送される可能性があります（A から F までの商品は明らかに N 台のトラックを満たすことができますが、ルートに従って輸送する必要があります）。システムで確立されていますが、システムによってブロックされているため、ルートが固定されているため、より多くの道路しか使用できず、人的作業と輸送のコストが増加します。
これに基づいて、専門家はコストを削減し、効率を向上させるビジネス チャンスを発見しました。これは、システムが上記の状況にさらに柔軟に対応し、リソースの究極の利用を実現できるように、このルーティング ラインとルールを有効にすることです。たとえば、多数の注文がある場合、それらはすべて A から宛先 F 宛てです。システム内の静的回線構成は A->B->D->F だけです。しかし、システムの監視と計算の結果、 A から F までの商品はトラック 2 台分に相当します。このとき、A から F までの注文に対して新しいルートが一時的に生成されます。同時に、商品は A サイトで受領および出荷されます。ルーティングラインのマッチングを伴うこの一時的なルーティングシナリオは、ユーザーの習慣を変えることなく全体的なコストを削減でき、目的地までの輸送効率も大幅に向上します。
この専門家が提案したプランは非常に優れており、広く皆様に評価され、プロジェクト発足後は順調な開発段階に入り、幸運にも私はその開発と提供を主導するという重要な任務を任されることになりました。このプロジェクト。
ルーティング回路への変更は、いくつかの隅から隅までの補助クエリ、統計レポート、その他の機能だけでなく、注文の実際の操作プロセス全体を通じて実行されることを言及する価値があります。そのため、依然としてプレッシャーがかかります。確かに、この期間中はかなり回り道をしましたが、最終的な結果は良好でした。その後でも、同様のルーティング ラインを変更する必要がいくつかありました。しかし、この変換に基づいて、簡単に対処できます。これは記事の後半で説明します。
ここまで言って、すべてがナンセンスだと感じますか? (笑)、確かに少し長くなっています。 次に、Menhui Road を見て、断片的ではありますが、達成感のある全体的な変化のプロセスを再現してみましょう。 。
2. アイデアと方法
以降の記事で説明するパーティショニングは、ルーティングの一致ルールの意味です。
まずは、実際の操作プロセスの簡単な模式図を見てみましょう。
パーティション マッチング ルールは各サイトの実際の操作プロセスに関与しますが、同時にルーティング マッチング ルールは一部の補助操作のクエリ機能やレポート機能にも関与するため、パーティション マッチング ルールを変更する必要がある場合には、その場合、次のような問題点に直面することになります
上記の問題点に基づいて、私はこのモジュールを再構成して修正することにしました。第一に、この課題を通じて自分自身を改善し、第二に、将来このルールを再度変更する可能性への道を開くことです。上記の問題点を具体的に解決するにはどうすればよいでしょうか?これが私がやったことです
これを見て、別の問題が発生するのではないかと疑問に思う人もいるかもしれません。シーンが失われることはありませんが、コード変更に達するとすべてのシーンが有効になりますが、一部のシーンの元のシーンは変更されるのでしょうか?ここの学生は確かに非常に慎重だと思います。クロージャを強制すると、この新しい問題が実際に発生します。したがって、統合クロージャは、各シーンの差別化された処理をサポートするために拡張と予約フックをサポートする必要があります。これはかなり抽象的です。たとえば、一般的なシナリオ ルールでは、すべての注文はシステムの確立された構成のゾーニング ルールに従って転送されますが、現在、一部の販売者は目的地に迅速に配送するためにいくつかのサービスを開始しています。マーチャントの注文 パーティションのマッチングと輸送に関して、既存の一般的なルールを使用することはできなくなりました。高速輸送の目的を達成するには、新しいルールに従ってパーティションのマッチングを実行する必要があります。これが内部の違いです。
では、責任連鎖モデルとは一体何なのでしょうか?
Daniel による定義: 複数のオブジェクトにリクエストを処理する機会を与え、リクエストの送信者と受信者の間の結合関係を回避します。これらのオブジェクトはチェーンに接続され、リクエストはオブジェクトが処理するまでチェーンに沿って渡されます。
既存のシステムの実際のビジネスに基づいて、それをどのように適用するかについて話しましょう。 既存のパーティション マッチング ルールが静的なパーティション マッチングであることは、冒頭の章の背景ですでに紹介しました (特定のビジネス ポイントツーポイント、特定のビジネスなど)範囲領域へのビジネス ポイント) 待ってください。具体的なビジネスの詳細については説明しません。ここには多数の一致ルールがあることを知っておいてください。) 次に、ダイナミクスをサポートする新しいルールを追加する必要があります (これもさまざまです)。ここでは、各パーティション ルールをパーティション タイプとして定義し、各パーティション タイプをパーティション ノードとして定義して、各リクエストが一致する行を見つけられるようにします。このチェーン。
ビジネスの詳細は比較的機密性が高いため、主要な設計パターンの適用の理解に影響を与えないため、記事では詳細には開示されません。
定義と上記の分析を組み合わせると、実際の状況は責任連鎖設計パターンの使用に適しているでしょうか?上記の問題点が解決でき、全体的なメリットがデメリットを上回るのであれば、適用可能であると私は考えています。まず、このモデルを使用して変換する利点は次のとおりです。
もちろん、このモデルにはいくつかの欠点もあります。責任の連鎖が比較的長い場合、各リクエストが連鎖全体を横断するため、同時に、理解していない学生にとってはデバッグがより複雑になる可能性があります。ビジネス。
全体として、利点は、現在の問題点を解決し、その後の拡張を容易にすることですが、欠点のパフォーマンス部分は、テンプレート モードで予約されているフック関数を組み合わせることでスキップできることです (現在のリクエストが現在のパーティション ノードに適していない場合)ルール ) を利用してパフォーマンスの問題による影響を最小限に抑えると同時に、開発者がビジネスを理解することも必要です。したがって、全体的にはメリットがデメリットを上回っているように見えます。
ここまでは述べましたが、まず変換前と変換後のパーティション モジュールの簡単な比較図を見てみましょう。
この図は非常に単純ですが、比較の意味は明らかです。変換前: パーティション マッチングとビジネス処理が結合されています。変換後: パーティション マッチングはチェーンであり、その中にはビジネス ロジック処理がありません。結合から解放された拡張機能もサポートされています。これを見て混乱する人もいるかもしれません。上記では、動的一致ルールが 1 つだけ追加されたと述べていませんでしたか? チェーン内に非常に多くのノードがあるのに、まだ 2 つのチェーンが存在するのはなぜでしょうか。ここで少し説明します。現在の 2 つのチェーンは多くの需要バージョンの変更を経験していますが、主に提供されるソース ビジネス指定のシナリオがそれぞれ異なるため、その違いは大きくないようです。それぞれの動作を妨げるため、この記事の多くの場所で紹介されているノードも後から追加され、現在までシステムで使用されているノード ルールです (これは記事の冒頭で述べたものです:案の定、それはまだです。私は賢いので、「予言」は現実になりました、ここで建設期間を短縮するための拡張をサポートする重要性をお伝えします。
3. 実践的なプロセス
多くの読者は、上記の内容が、パフォーマンスへの影響を最大限に回避するためにテンプレート モードと統合して閉じて結合することについて述べているため、責任の連鎖は 1 つの設計モードではサポートできないことに気づくと思います。
確かに、単一の責任チェーンのデザイン パターンを使用するだけでは、上記の効果を達成することはできません。ここでは、ファクトリ、テンプレート、および責任チェーン パターンを組み合わせます。チェーンの Bean を取得します。テンプレートは、一般的なメソッド、メソッド間の呼び出し、スイッチ、前処理と後処理、微分、およびサブクラスの実装用に予約されたその他のメソッドを設定するために使用されます。いくつかの簡単な例を示します。ノードは次のようにクラス図を表示します。
結局のところ、このセクションは比較的単純です。上記のクラス図は、コード内のほとんどの実用的なアプリケーションであり、実際の呼び出しでは、Bean チェーンが特定のファクトリを通じて取得されます。パーティションのマッチング。
4. 実践プロセスの考え方と効果の評価
変換後の結果は、主にその後の拡張とメンテナンスに反映されます。記事の冒頭で述べたように、パーティションの一致ルールが変更されると、最も直接的に現れるのは構築期間です。このブロックを初めて取得する 新しいルーティング ルールの要件を変更する場合、研究開発側での全体の実際の構築期間は 45 日です。言うまでもなく、一度バグが発生すると、テスト期間は保証されません (動的ノードに相当)上の図のノード内)
しかし、その後すぐに、マッチング ルールの新しい要件が再び追加されました (上記のノードのカープール ノードに対応)。構築期間はほぼ半分に短縮され、最適な 45 日は 27 日に短縮されました。要件には、他の非パーティション化モジュールの変換も含まれます。もちろん、最初のバージョンの変換にはいくつかの完璧な側面がありましたが、その後、必要に応じて最適化されました。
次の 2 つは、いわゆる工期の消滅を具体化したものです。1 つは最初のボード ゾーニング ルール要件であり、もう 1 つは最近の B ネットワーク統合要件におけるダイレクト ゾーニング ルールです。
正直、データを見なかった頃は、これほど大きな効果を期待していなかったので、今振り返ると、まさかデザインパターンの適用で工期が短縮できるとは誰が考えていただろうかとショックを受けています。 1 神まであと 45 日、これは信じられないほどです。
もちろん、改善およびアップグレードできる領域もいくつかあります。現時点では、責任チェーン ノードのアセンブリは手動で指定されており、自動アセンブリに変更できます (別のビジネス シナリオの変換ですでに実装しています)。同期変換もここで実行されます)。もう 1 つはノードの数を制御することです。ノード数が多すぎる場合は、互換性の解決策を検討する必要があるかもしれません。
ことわざにあるように、水滴を貫くのに 1 日はかからず、3 フィートの氷を凍らせるのに 1 日もかかりません。強力なツールや新しいテクノロジーを追求することは確かに可能ですが、そうしないでください。日々の業務の小さな変化は、短期間では何も見えないかもしれませんが、量的な変化が質的な変化につながると、大きな成果が得られると思います。