De: http://www.artima.com/lejava/articles/designprinciples4.html

Erich Gamma: Sigo pensando que es verdad incluso después de diez años. La herencia es una forma genial de cambiar el comportamiento. Pero sabemos que es frágil, porque la subclase puede hacer fácilmente suposiciones sobre el contexto en el que se llama a un método que anula. Hay un acoplamiento estrecho entre la clase base y la subclase, debido al contexto implícito en el que se llamará al código de subclase que conecto. La composición tiene una mejor propiedad. El acoplamiento se reduce con solo tener algunas cosas más pequeñas que se conectan a algo más grande, y el objeto más grande simplemente llama al objeto más pequeño. Desde el punto de vista de la API, definir que un método se puede anular es un compromiso más fuerte que definir que se puede llamar a un método.

No entiendo lo que quiere decir. ¿Alguien podría explicarlo?

Un compromiso es algo que reduce sus opciones futuras. Publicar un método implica que los usuarios lo llamarán, por lo tanto, no puede eliminar este método sin romper la compatibilidad. Si lo hubiera guardado private, no podrían llamarlo (directamente), y algún día podría refactorizarlo sin problemas. Por lo tanto, publicar un método es un compromiso más fuerte que no publicarlo. Publicar un método reemplazable es un compromiso aún más fuerte. ¡Sus usuarios pueden llamarlo, y pueden crear nuevas clases donde el método no hace lo que usted cree que hace!

Por ejemplo, si publica un método de limpieza, puede asegurarse de que los recursos se desasignen correctamente siempre que los usuarios recuerden llamar a este método como lo último que hacen. Pero si el método es reemplazable, alguien podría anularlo en una subclase y no llamar super. Como resultado, un tercer usuario podría usar esa clase y causar una pérdida de recursos a pesar de que llamaron cleanup()al final . Esto significa que ya no puede garantizar la semántica de su código, lo cual es algo muy malo.

Esencialmente, ya no puede confiar en ningún código que se ejecute en métodos reemplazables por el usuario, porque algunos intermediarios podrían anularlo. Esto significa que debe implementar su rutina de limpieza completamente en privatemétodos, sin la ayuda del usuario. Por lo tanto, generalmente es una buena idea publicar solo finalelementos a menos que estén destinados explícitamente a ser anulados por los usuarios de API.

Si publica una función normal, otorga un contrato unilateral:
¿Qué hace la función si se llama?

Si publica una devolución de llamada, también otorga un contrato unilateral: ¿
Cuándo y cómo se llamará?

Y si publica una función reemplazable, ambas son a la vez, por lo que otorga un contrato a dos caras: ¿
cuándo se llamará y qué debe hacer si se llama?

Incluso si sus usuarios no abusan de su API (al romper su parte del contrato, que puede ser prohibitivamente costoso de detectar), puede ver fácilmente que este último necesita mucha más documentación, y todo lo que documenta es un compromiso, lo que limita Sus otras opciones.

Un ejemplo de incumplir un contrato de este tipo a doble cara es el movimiento desde showy hidehacia setVisible(boolean)en java.awt.Component .

La respuesta de Kilian Foth es excelente. Solo me gustaría agregar el ejemplo canónico * de por qué esto es un problema. Imagine una clase de punto entero:

class Point2D {
    public int x;
    public int y;

    // constructor
    public Point2D(int theX, int theY) { x = theX; y = theY; }

    public int hashCode() { return x + y; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point2D) ) { return false; }

        Point2D that = (Point2D) o;

        return (x == that.x) &&
               (y == that.y);
    }
}

Ahora subclasifiquemos para que sea un punto 3D.

class Point3D extends Point2D {
    public int z;

    // constructor
    public Point3D(int theX, int theY, int theZ) {
        super(x, y); z = theZ;
    }

    public int hashCode() { return super.hashCode() + z; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point3D) ) { return false; }

        Point3D that = (Point3D) o;

        return super.equals(that) &&
               (z == that.z);
    }
}

Súper simple! Usemos nuestros puntos:

Point2D p2a = new Point2D(3, 5);
Point2D p2b = new Point2D(3, 5);
Point2D p2c = new Point2D(3, 7);

p2a.equals(p2b); // true
p2b.equals(p2a); // true
p2a.equals(p2c); // false

Point3D p3a = new Point3D(3, 5, 7);
Point3D p3b = new Point3D(3, 5, 7);
Point3D p3c = new Point3D(3, 7, 11);

p3a.equals(p3b); // true
p3b.equals(p3a); // true
p3a.equals(p3c); // false

Probablemente se esté preguntando por qué estoy publicando un ejemplo tan fácil. Aquí está el truco:

p2a.equals(p3a); // true
p3a.equals(p2a); // FALSE!

Cuando comparamos el punto 2D con el punto 3D equivalente, obtenemos verdadero, pero cuando invertimos la comparación, obtenemos falso (porque p2a falla instanceof Point3D).

Conclusión

1. Por lo general, es posible implementar un método en una subclase de tal manera que ya no sea compatible con la forma en que la superclase espera que funcione.

2. En general, es imposible implementar equals () en una subclase significativamente diferente de una manera que sea compatible con su clase padre.

Cuando escribe una clase que pretende permitir que las personas subclasifiquen, es una muy buena idea redactar un contrato sobre cómo debe comportarse cada método. Aún mejor sería un conjunto de pruebas unitarias que las personas podrían ejecutar contra sus implementaciones de métodos anulados para demostrar que no violan el contrato. Casi nadie hace eso porque es demasiado trabajo. Pero si te importa, eso es lo que debes hacer.

Un gran ejemplo de un contrato bien enunciado es Comparator . Simplemente ignore lo que dice .equals()por las razones descritas anteriormente. Aquí hay un ejemplo de cómo Comparator puede hacer cosas .equals()que no puede .

Notas

1. El elemento 8 "Java efectivo" de Josh Bloch fue la fuente de este ejemplo, pero Bloch usa un ColorPoint que agrega un color en lugar de un tercer eje y usa dobles en lugar de ints. El ejemplo de Bloch en Java está básicamente duplicado por Odersky / Spoon / Venners que hicieron que su ejemplo estuviera disponible en línea.

2. Varias personas se han opuesto a este ejemplo porque si le informa a la clase principal sobre la subclase, puede solucionar este problema. Eso es cierto si hay un número suficientemente pequeño de subclases y si el padre las conoce todas. Pero la pregunta original era sobre hacer una API para la cual alguien más escribirá subclases. En ese caso, generalmente no puede actualizar la implementación principal para que sea compatible con las subclases.

Prima

Comparator también es interesante porque soluciona el problema de implementar equals () correctamente. Mejor aún, sigue un patrón para solucionar este tipo de problema de herencia: el patrón de diseño de la Estrategia. Las clases de tipo que entusiasman a la gente de Haskell y Scala también son el patrón de estrategia. La herencia no es mala o incorrecta, solo es complicada. Para leer más, consulte el artículo de Philip Wadler Cómo hacer que el polimorfismo ad-hoc sea menos ad-hoc.

La herencia debilita la encapsulación

Cuando publica una interfaz con la herencia permitida, aumenta sustancialmente el tamaño de su interfaz. Cada método reemplazable podría ser reemplazado y, por lo tanto, debe considerarse como una devolución de llamada proporcionada al constructor. La implementación proporcionada por su clase es simplemente el valor predeterminado de la devolución de llamada. Por lo tanto, se debe proporcionar algún tipo de contrato que indique cuáles son las expectativas sobre el método. Esto rara vez ocurre y es una de las principales razones por las cuales el código orientado a objetos se llama quebradizo.

A continuación se muestra un ejemplo real (simplificado) del marco de colecciones de Java, cortesía de Peter Norvig ( http://norvig.com/java-iaq.html ).

Public Class HashTable{
    ...
    Public Object put(K key, V value){
        try{
            //add object to table;
        }catch(TableFullException e){
            increaseTableSize();
            put(key,value);
        }
    }
}

Entonces, ¿qué sucede si subclasificamos esto?

/** A version of Hashtable that lets you do
 * table.put("dog", "canine");, and then have
 * table.get("dogs") return "canine". **/

public class HashtableWithPlurals extends Hashtable {

    /** Make the table map both key and key + "s" to value. **/
    public Object put(Object key, Object value) {
        super.put(key + "s", value);
        return super.put(key, value);
    }
}

Tenemos un error: ocasionalmente agregamos "dog" y la tabla hash obtiene una entrada para "dogss". La causa fue alguien que proporcionó una implementación de put que la persona que diseñó la clase Hashtable no esperaba.

La herencia rompe la extensibilidad

Si permite que su clase se subclasifique, se compromete a no agregar ningún método a su clase. De lo contrario, esto podría hacerse sin romper nada.

Cuando agrega nuevos métodos a una interfaz, cualquier persona que haya heredado de su clase deberá implementar esos métodos.

Si se pretende llamar a un método, solo debe asegurarse de que funcione correctamente. Eso es. Hecho.

Si un método está diseñado para ser anulado, también debe pensar cuidadosamente sobre el alcance del método: si el alcance es demasiado grande, la clase secundaria a menudo necesitará incluir código copiado del método principal; Si es demasiado pequeño, será necesario anular muchos métodos para tener la nueva funcionalidad deseada; esto agrega complejidad y un recuento de líneas innecesario.

Por lo tanto, el creador del método padre debe hacer suposiciones sobre cómo la clase y sus métodos podrían anularse en el futuro.

Sin embargo, el autor habla sobre un tema diferente en el texto citado:

Pero sabemos que es frágil, porque la subclase puede hacer fácilmente suposiciones sobre el contexto en el que se llama a un método que anula.

Considere el método aque normalmente se llama desde el método b, pero en algunos casos raros y no obvios desde el método c. Si el autor del método de anulación pasa por alto el cmétodo y sus expectativas sobrea , es obvio cómo las cosas pueden salir mal.

Por lo tanto, es más importante que ase defina clara e inequívocamente, bien documentado, "hace una cosa y lo hace bien", más que si fuera un método diseñado únicamente para ser llamado.