Des classes finales en Java qui ne devraient pas être finales ou vice versa?

Question

On m'a posé cette question dans une interview récemment:

Pouvez-vous nommer n'importe quelle classe de l'API Java finale qui ne devrait pas l'être ou qui ne l'est pas et devrait l'être?

Je ne pouvais penser à aucun. La question implique que je devrais connaître toutes les classes d'API comme le dos de ma main, ce que personnellement je ne m'attendrais pas à ce qu'un développeur Java sache.

Si quelqu'un connaît de telles classes, veuillez fournir des exemples.

Answer 1

java.awt.Dimension n'est pas définitif ou immuable et aurait dû l'être. Tout ce qui renvoie une dimension (par exemple un objet Window) doit faire des copies défensives pour empêcher les appelants de faire des choses désagréables.

Answer 2

Les premiers exemples qui viennent à l'esprit sont certains de la non-Nombre final des sous-classes, comme BigDecimal et BigInteger, ce qui devrait probablement être définitifs.

En particulier, l'ensemble de leurs méthodes peuvent être surchargée. Qui vous permet de créer une fracture BigDecimal, par exemple:

public class BrokenBigDecimal extends BigDecimal {
    public BigDecimal add(BigDecimal augend) {
        return BigDecimal.ZERO;
    }
}    

Que pourrait engendrer de graves problèmes si vous recevez BigDecimal à partir d'un code non fiable par exemple.

Pour paraphraser Efficace Java:

• La conception et le document de l'héritage ou de l'autre de l'interdire
• Les Classes doivent être immuable, sauf si il ya une très bonne raison de les rendre mutable

Answer 3

À mon avis, votre réponse doit avoir été que c'est une question de goût classes final et qui ne le sont pas.

Il y a de bonnes raisons pour faire de la Integer, Double et String tous final.

Il y a de bonnes raisons de se plaindre à ce sujet.

Puis il y a BitSet, BitInteger etc. qui pourraient être apportées final.

Il y a un certain nombre de situations où les classes ne sont pas final, mais ils ont aussi ne peut pas être prolongé raisonnablement, donc ils ont probablement dû être final.

De s'en prendre à une catégorie donnée: BitSet. Il n'est pas final, mais vous ne pouvez l'étendre à ajouter un peu shift de l'opération. Ils pourraient aussi bien avoir fait final puis de, ou nous permettre d'ajouter une telle fonctionnalité.

Answer 4

La classe Date saute. Il s'agit d'une classe de valeurs simples mutable (essentiellement un wrapper autour d'un long ), mais une bonne heuristique est que les classes de valeurs simples doivent être immuables. A noter également ses nombreuses méthodes obsolètes: plus de preuves que le design était bâclé. La mutabilité du Date est une source de bugs, nécessitant une copie défensive disciplinée .

Answer 5

une qui ne l'est pas et doit être

La plupart des final les classes en java sont conçus de telle sorte en raison w/ considérations sur la sécurité à l'esprit, dans l'ensemble il y a relativement peu de finales. Par exemple, java.util.String est définitive pour cette raison. Il en est beaucoup d'autres. Certaines classes w/ privé c-tor sont déclarées final (en Mathématiques, StrictMath), mais il n'a pas d'importance dans ce cas.

Fondamentalement, sauf s'il existe des problèmes de sécurité, je ne m'inquiète pas si la classe est finale, mais vous pouvez toujours utiliser le non-public c-tor w/ une usine, a pour effet de limiter la capacité de la sous-classe. Habituellement, c'est ma manière préférée car elle permet de colis-privé sous-classement.

En bref: je ne peux pas penser à une classe finale qui ne devrait pas être, cependant, il ya certains qui pourraient avoir été. Par exemple, java.lang.Thread finale pourraient ne pas avoir besoin de protéger vs malveillant clone().