En una clase Java, un método puede definirse comofinal, 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 útil para proteger contra la anulación accidental, 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étodofinal el diseñador de clase promesas este método siempre funcionará según lo descrito o implícito. Pero a menudo esto puede estar fuera de la influencia del autor de la clase, si lo que está haciendo el método es más complicado que simplemente entregar unpropieda.

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

¿Qué tipo de "contrato" hace unfinal promesa de método?