Clases Abstractas e Interfaces (Java).

    Antes de iniciar considere el Ejemplo de late binding; el cual se utilizó en la entrada POO - Consideraciones adicionales para reforzar la idea de polimorfismo.

    En directa relación con el ejemplo anterior, no sólo por el polimorfismo, sino como complemento de los mecanismos de abstracción que proporciona un lenguaje de programación, se comentarán brevemente dos aspectos de Java relacionados con dichos mecanismos:

1. Las clases abstractas.
2. Las Interfaces.
   

    Las clases abstractas y las interfaces son similares en algunos aspectos: no se puede crear una instancia de ellas, y ambas pueden contener una combinación de métodos declarados con o sin una implementación.

 

    Por otro lado, también existen diferencias importantes: con las clases abstractas se pueden declarar campos que no son static y final, así como definir métodos concretos públicos, protegidos y privados. Con las interfaces, todos los campos son automáticamente públicos, static y final; así mismo, todos los métodos que declara o define (como métodos predeterminados) son públicos.

 

    Otra diferencia importante es que una clase determinada puede heredar (extends) sólo una clase (no existe herencia múltiple), ya sea abstracta o no; mientras que esa misma clase puede implementar cualquier cantidad de interfaces.

 

    Entonces ¿qué se debería utilizar: clases abstractas o interfaces? Una guía que podría ser útil es la siguiente (The Java Tutorials): considere utilizar clases abstractas si se enfrenta con alguna de estas situaciones:

• Desea compartir código entre varias clases estrechamente relacionadas (clases con un alto grado de acoplamiento).
• Espera que las clases que amplían su clase abstracta tengan muchos métodos o campos comunes, o requieran modificadores de acceso que no sean públicos (como protegido y privado).
• Desea declarar campos no static o no final. Esto le permite definir métodos que pueden acceder y modificar el estado del objeto al que pertenecen.
  

    Por otro lado, considere usar interfaces si se enfrenta con alguna de estas otras situaciones:

• Espera que clases no necesariamente relacionadas implementen su interfaz. Por ejemplo, las interfaces Comparable y Cloneable del API son implementadas por muchas clases no relacionadas.
• Desea especificar el comportamiento de un tipo de datos en particular, pero no le preocupa quién implementa su comportamiento.
• Desea aprovechar la herencia múltiple de tipos.

    Respecto a las interfaces, en general existe una serie muy amplia de situaciones en las que es importante que grupos distintos de programadores acepten un "contrato" que explique o determine cómo interactúa su software. Cada grupo debe poder escribir su código sin saber cómo está escrito el código del otro grupo. En términos generales puede decirse que las interfaces son tales contratos.

 

    Con base en lo anterior y en estrecha relación con el Ejemplo de late binding (inicial de esta sección), considere ahora otros dos ejemplos que implementan de manera distinta la misma idea utilizando los conceptos y mecanismos descritos previamente. En algunas ocasiones y dependiendo de las habilidades, criterios y experiencia del programador, se puede utilizar el enfoque de clases abstractas e interfaces de manera intercambiable, pero también pueden ser utilizados de forma complementaria; los ejemplos que se presentan a continuación pretenden clarificar lo anterior. El lector interesado en aprender debe tomarse el tiempo que considere necesario para la comprensión de ambos ejemplos. Se sugiere seguir el orden propuesto:

1. Ejemplo de figuras geométricas utilizando una clase abstracta.
2. Ejemplo de figuras geométricas utilizando una clase abstracta y una interfaz.

    Una vez comprendidos los ejemplos, consulte la sección de ejercicios selectos de Programación Orientado a Objetos; particularmente el Ejercicio 5 de la Parte II.