Java アプリケーションのリファクタリング/レビューを行っています
私がそうしているとき、いくつかのメソッドにはObject
、String
、Boolean
などの戻り値があることを示していますが、戻り値はどの場所でも使用されていません。メソッドの呼び出しのみを行いました。
そのため、アプリケーションのパフォーマンスの問題が発生するため、それらをそのままにしておくとさまよいます。
それらを無効に変更する必要がありますか、それともそのままにしておく必要がありますか?
Java アプリケーションのリファクタリング/レビューを行っています
私がそうしているとき、いくつかのメソッドにはObject
、String
、Boolean
などの戻り値があることを示していますが、戻り値はどの場所でも使用されていません。メソッドの呼び出しのみを行いました。
そのため、アプリケーションのパフォーマンスの問題が発生するため、それらをそのままにしておくとさまよいます。
それらを無効に変更する必要がありますか、それともそのままにしておく必要がありますか?
さらに、パフォーマンスが低下するだけでなく、メソッドの構造が不適切です。
メソッドの戻り値がプログラムで使用されない場合は、それを返す理由がないため、メソッドの戻り値の型を にする必要がありますvoid
。
戻り値の型をそのままにしておくことでパフォーマンスが低下するとは思いません。
そうは言っても、それらを削除する必要があると思います。その理由は、それらが本質的にデッド コードだからです。戻り値の型を中心に展開するこれらのメソッドには、未知のバグが潜んでいる可能性があります-それらは使用されていないため不明です。誰かがいつかそれらを使用することを決定した場合、これは潜在的な危険です.
さらに、それらを維持すると、メンテナンスの負担が増加します。誰かがこれらのメソッドのいずれかに触れるたびに、戻り値の型について (不必要に) 考えなければなりません。
これは本質的に YAGNI に帰着します。
の値が使用されていない場合、値を返さないでください。void
代わりに使用してください。時々 、使用されていないゲッターがいくつか見られますが、実際にはそれらはWebフレームワークによって使用されています。メソッドが使用されていないかどうかを判断するのは困難です。使用されても戻り値は無視されます。戻り値を無視しないという制限はありません。
私の意見では、API が正しく使用されていないか、設計が正しくありません。
API が正しく設計されている場合、API ユーザーがメソッドの戻り値の型を使用しないのはなぜですか? この場合、ユーザーは間違っているに違いありません。
一方、API が正しく設計されていない場合、現在の状態で使用する意味は何ですか? 返された情報が不要な場合は、API を修正してメソッドを無効にします。
優れた API 設計と比較すると、パフォーマンスに関する考慮事項はほとんど重要ではないと思います。パフォーマンスは後からいつでも改善できますが、API の変更は非常に難しく、費用がかかります。