アイテムの過負荷は慎重に使用してください

過負荷の問題:

• CollectionClassifier プログラムの例のように、メソッドのオーバーロードは予期せぬ動作を引き起こす可能性があります。これは、呼び出すメソッドの選択が実行時ではなくパラメーターの型に基づいてコンパイル時に行われるためです。

オーバーロードと上書き:

• オーバーロードではコンパイル時にメソッドが選択されますが、オーバーライドでは実行時に型に基づいて正しいメソッドが選択されるため、動作がより予測可能になります。

混乱を招くオーバーヘッドを回避します:

• パラメータのセットに対してどのメソッドが呼び出されるのかが明確でない場合、オーバーロードはプログラマを混乱させる可能性があります。これはパブリック API で特に問題になります。

おすすめ:

• 同じ数のパラメーターを持つ 2 つのオーバーロードをエクスポートすることは避けてください。
• オーバーロードではなく、メソッドに別の名前を付けます (writeInt や writeBoolean など)。
• 可変引数を使用する場合は、オーバーロードを避けてください。

ジェネリックとオートボクシングのケース:

• Java でのジェネリックスとオートボクシングの導入により、List.remove の例に示すように、複数のオーバーロードが存在するために混乱を招く動作をする可能性があるオーバーロードの問題が発生しました。

関数インターフェイスとラムダ:

• Java 8 でのラムダの追加により、特に関数型インターフェースが「根本的に異なる」ものではない場合、関数型インターフェースを受け取るメソッドをオーバーロードすることによって混乱が生じるリスクが増加しました。

実際的な解決策:

• instanceof を使用した明示的なテストにより、オーバーロードに関連する問題を回避できます。
• 根本的に異なるパラメーター (相互に変換できない型) を持つオーバーロードは、混乱を避けます。
• コンストラクターとオーバーロード: コンストラクターは常にオーバーロードされますが、静的ファクトリーを使用すると、この複雑さの一部を回避できます。

正当な例外:

• 古いクラスの適応など、場合によってはオーバーロードが必要になる場合がありますが、オーバーロードされたメソッドが同じパラメーターで呼び出されたときに同じように動作するように注意して使用する必要があります。

結論:

• オーバーロードは慎重に使用する必要があります。技術的には可能ですが、多くの場合、より明確で予測可能なコードを確保するために、メソッドに別の名前を付けるか、混乱を招くオーバーロードを避けることが望ましいです。

本の例:

以上がアイテムの過負荷は慎重に使用してくださいの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。