java - Java の final クラスは final またはその逆であってはなりませんか?

Question

最近のインタビューでこんな質問をされました。

最終的な Java API のクラスのうち、そうであってはならないもの、またはそうであってはならないものを指定できますか?

私は何も考えられませんでした。この質問は、すべての API クラスを手の甲のように知っている必要があることを意味しますが、個人的には Java 開発者が知っているとは思っていません。

誰かがそのようなクラスを知っているなら、例を挙げてください。

Answer 1

私の意見では、あなたの返事は、どのクラスが最終的なもので、どのクラスがそうでないかは好みの問題であるということでした。

Integer作るのには十分な理由がDoubleありStringますfinal。

これについて不平を言うのには十分な理由があります。

BitSetなどBitIntegerなどありますfinal。

クラスが ではない状況は数多くありますが、final合理的に拡張することもできないため、おそらく final にするべきでした。

特定のクラスを選択するには: BitSet. ではありませんが、ビット操作finalを追加するために拡張することはできません。shift彼らはそれを作ったかもしれませんしfinal、そのような機能を追加することを許可したかもしれません.

Answer 2

クラスはDate飛び出します。これは変更可能な単純な値クラス（基本的にはのラッパーlong）ですが、優れたヒューリスティックは、単純な値クラスは不変でなければならないということです。また、その多数の非推奨の方法にも注意してください。設計が失敗したという証拠が増えています。の可変性Dateはバグの原因であり、統制のとれた防御コピーが必要です。

Answer 3

そうではなく、あるべきもの

Java のほとんどの最終クラスは、セキュリティ上の考慮事項を念頭に置いて設計されているため、全体として最終クラスは比較的少数です。たとえばjava.util.String、まさにその理由で final です。他の多くの人もそうです。プライベート c-tor を持ついくつかのクラスは final と宣言されています (Math、StrictMath) が、そのような場合は問題になりません。

基本的に、関連するセキュリティの問題がない限り、クラスが最終的であるかどうかは気にしませんが、サブクラス化する機能を効果的に制限するファクトリで非パブリック c-tor をいつでも使用できます。通常、これはパッケージ プライベート サブクラス化を可能にするため、私の好みの方法です。

要するに、そうであってはならない最終クラスは考えられませんが、そうなる可能性があるものもいくつかあります。たとえばjava.lang.Thread、 final であることは、悪意のあるものに対して保護する必要がなかった可能性がありますclone()。