¿Por qué es la clase java.util.Scanner declaró 'final'?

Question

escáner clase para la lectura de múltiples archivos similares. Me gustaría extenderlo para asegurarse de que todo el uso de la misma delimitador y también puedo añadir métodos como skipUntilYouFind (String thisHere) que todas válidas para todos ellos.

Me puede hacer una clase de utilidad que ellos contienen, o incrustar la clase escáner como una variable dentro de otra clase, pero esto es más engorroso.

He encontrado algunas razones para declarar una clase final, pero por qué se hace aquí?

Answer 1

Probablemente debido a su ampliación y sobrescribir algunos de sus métodos, probablemente romperlo. Y lo que es más fácil a los métodos de sobrescritura expondría a gran parte de los trabajos internos, por lo que si en el futuro se deciden a cambiar los (por rendimiento o algunas otras razones), que sería más difícil para ellos cambiar la clase sin romper todas las clases que extenderlo.

Por ejemplo, considere la siguiente método en la clase:

public boolean nextBoolean()  {
    clearCaches();
    return Boolean.parseBoolean(next(boolPattern()));
}

Digamos que quiere sobrescribir esto porque quiere hacer 'impresionante' evaluar a un valor lógico 'verdadero' (por cualquier motivo). Si se sobrescribe, no se puede llamar super.nextBoolean (), ya que ello consumir el siguiente token utilizando la lógica predeterminada. Pero si usted no llama super.nextBoolean (), no serán llamados clearCaches (), posiblemente, rompiendo los otros métodos no sobrescritos. No se puede llamar clearCaches () porque es privado. Si lo hicieron protegida, pero luego se dio cuenta de que está causando un problema de rendimiento, y quería una nueva aplicación que hace cachés no claras más, entonces se podría romper su aplicación sobrescribe que todavía se llama eso.

Así que básicamente es para que puedan cambiar fácilmente las partes ocultas dentro de la clase, que son bastante complejas, y que le protege de hacer una clase hija roto (o una clase que podría ser fácilmente roto).

Answer 2

supongo que se debe a razones de seguridad. Esta clase lee la entrada del usuario, de manera que alguien con malas intenciones podría extenderse, modificarlo de comportamiento y que estaría atornillado. Si es final, no es tan fácil para el malo, porque si él hace su propio tipo de escáner (no java.util.Scanner), los principios de polimorfismo se romperían. Ver el malo puede ser lo suficientemente inteligente como para escribir un bot / script que lo hace automáticamente en servidores remotos ... Incluso puede hacerlo por la carga de clase dinámica en la aplicación compilada.

Answer 3

Creo que el enlace que ya ha proporcionado lo explica todo.

En su caso parece que se debe preferir la composición en lugar de la herencia de todos modos. Usted está creando una utilidad que tiene un comportamiento predefinido, y que puede ocultar algunos (o todos) de los detalles de la clase escáner.

he visto muchas implementaciones que utiliza la herencia con el fin de cambiar un comportamiento. El resultado final fue por lo general un diseño monolítico, y en algunos casos, un contrato roto, y / o el comportamiento roto.