ser - Método ''final'' de Java: ¿qué promete?

polimorfismo java

Question

En una clase de Java, un método se puede definir como final , para marcar que este método no se puede anular:

public class Thingy {
    public Thingy() { ... }
    public int operationA() {...}
    /** this method does @return That and is final. */
    public final int getThat() { ...}
}

Eso está claro, y puede ser de alguna utilidad proteger contra anulaciones accidentales, o tal vez el rendimiento, pero esa no es mi pregunta.

Mi pregunta es: desde el punto de vista de OOP, entendí que, al definir un método final el diseñador de clase promete que este método siempre funcionará como se describe o implícito. Pero a menudo esto puede estar fuera de la influencia del autor de la clase, si lo que el método está haciendo es más complicado que simplemente entregar una propiedad .

La restricción sintáctica es clara para mí, pero ¿cuál es la implicación en el sentido OOP? ¿El final es usado correctamente en este sentido por la mayoría de los autores de la clase?

¿Qué tipo de "contrato" promete un método final ?

Answer 1

¿Qué tipo de "contrato" promete un método final?

Mírelo de otra manera, cualquier método no final ofrece la garantía implícita de que puede anularlo con su propia implementación y la clase seguirá funcionando como se esperaba. Cuando no puede garantizar que su clase respalde la sobreescritura de un método, debe hacerlo definitivo.

Answer 2

Como se mencionó, el final se usa con un método Java para marcar que el método no puede ser anulado (para el alcance del objeto) u oculto (para estático). Esto permite que el desarrollador original cree una funcionalidad que no puede ser modificada por subclases, y esa es toda la garantía que brinda.

Esto significa que si el método se basa en otros componentes personalizables como campos / métodos no públicos, la funcionalidad del método final aún puede ser personalizable. Esto es bueno, aunque como (con polimorfismo) permite la personalización parcial.

Hay una serie de razones para evitar que algo se personalice, incluidos:

• Rendimiento : algunos compiladores pueden analizar y optimizar la operación, especialmente la que no tiene efectos secundarios.

• Obtenga datos encapsulados : observe objetos inmutables donde sus atributos se establecen en el momento de la construcción y nunca se deben cambiar. O un valor calculado derivado de esos atributos. Un buen ejemplo es la clase Java String .

• Confiabilidad y contrato : los objetos se componen de primitivos ( int , char , double , etc.) u otros objetos. No todas las operaciones aplicables a esos componentes deben ser aplicables o incluso lógicas cuando se usan en el objeto más grande. Los métodos con el modificador final se pueden usar para garantizar eso. La clase Counter es un buen ejemplo.

public class Counter {
    private int counter = 0;

    public final int count() {
        return counter++;
    }

    public final int reset() {
        return (counter = 0);
    }
}

Si el método public final int count() no es final , podemos hacer algo como esto:

Counter c = new Counter() {   
    public int count() {
        super.count();   
        return super.count();   
    } 
}

c.count(); // now count 2

O algo como esto:

Counter c = new Counter() {
    public int count() {
        int lastCount = 0;
        for (int i = super.count(); --i >= 0; ) {
            lastCount = super.count();
        }

        return lastCount;
    }
}

c.count(); // Now double count

Answer 3

En primer lugar, puede marcar clases final no abstractas, así como campos y métodos. De esta forma, no se puede subclasificar toda la clase. Entonces, el comportamiento de la clase será arreglado.

Acepto que los métodos final marcado no garantizan que su comportamiento será el mismo en las subclases si estos métodos están llamando a métodos no finales. Si el comportamiento de hecho debe ser arreglado, esto debe lograrse por convención y diseño cuidadoso. ¡Y no olvides mencionar esto en javadoc! (Documentación de java)

Por último, pero no menos importante, final palabra clave final tiene un papel muy importante en el Modelo de memoria de Java (JMM). JMM garantiza que para lograr la visibilidad de los campos final no necesita una sincronización adecuada. P.ej:

class A implements Runnable {
  final String caption = "Some caption";                           

  void run() {
    // no need to synchronize here to see proper value of final field..
    System.out.println(caption);
  }
}  

Answer 4

No estoy seguro de que pueda hacer ninguna afirmación sobre el uso de "final" y cómo eso afecta el contrato de diseño general del software. Se le garantiza que ningún desarrollador puede anular este método y anular su contrato de esa manera. Pero, por otro lado, el método final puede basarse en las variables de clase o instancia cuyos valores están establecidos por subclases, y puede llamar a otros métodos de clase que se anulan. Tan final es a lo sumo una garantía muy débil.

Answer 5

No, no está fuera de la influencia del autor de la clase. No puede anularlo en su clase derivada, por lo tanto, hará lo que el autor de la clase base pretendió.

http://download.oracle.com/javase/tutorial/java/IandI/final.html

Digno de mención es la parte donde sugiere que los métodos llamados por los constructores deben ser final .