論理判断がない場合はジャンプアドレスを定数に入れるだけですが、業務論理判断がある場合はカプセル化します。

純粋なジャンプ ロジックの場合は、別のメソッドにカプセル化する必要はなく、接続を定数ファイルに含めることができます。ここで述べたことは論理の 1 文に過ぎないため、ここでは論理的な変更はありませんが、変更される可能性があるのは接続アドレスであり、一元管理する場合は別の定数ファイルに入れます。

このリンクホッピングプロセスには、どのような条件でどのアドレスにジャンプするかなど、独自の論理的判断がある場合。その後、他の場所を呼び出すためのメソッドにカプセル化できます。このようにして、このロジック部分が変更されたときに変更する必要があるのは 1 か所だけです。

したがって、カプセル化するかどうか、また何をカプセル化するかは、変化するニーズによって異なります

前回のプロジェクトではすべてを直接書きましたが、カプセル化する必要はないと感じました。また、それによってパフォーマンスが向上するかどうかは、私自身で比較したことがないのでわかりません。

コードのカプセル化は、コードの重複を減らすことです。カプセル化すると、そのコードを参照するために別のコードを作成する必要があるため、コードの重複を減らすことができます。コードはあまり変わりません。

前提: 多くの場所で使用されるこのようなコードがあり、それぞれの場所でパーソナライズされた変更はあまりありません

私だったら、それを 1 か所に置き、次の目的で 1 か所から均一に呼び出します (グローバルでも、ユーティリティでも可能です)。

1. 将来の拡張の難易度を軽減します。後でさらに何かを追加する必要があることがわかった場合でも、簡単に変更できます

2. 修正時の作業負荷を軽減します。 href を変更したい場合、1 つずつ検索して置き換える必要がなく、エラーの可能性が減ります

3. デバッグが簡単。さまざまな場所にジャンプするのではなく、どこからジャンプすればよいかを正確に知ることができます。意味不明にジャンプした場合、この場所で中断ポイントが直撃するので、上を見上げると問題が見つかります。さまざまな場所で多くのブレークポイントに到達する必要がなくなります。

4. この単純なロジックでは、コードの利便性と単純さがコードのパフォーマンスよりもはるかに優れていることは明らかなので、パフォーマンスの問題は考慮しません