interfaz - ejercicios de clases abstractas e interfaces en java
Clase abstracta extiende clase concreta (5)
Básicamente es reutilizar selectivamente algún código existente (¿heredado?).
Por ejemplo : supongamos que alguien ya ha creado una clase C concreta (por supuesto, la implementación completa).
Ahora, ya que está diseñando un nuevo sistema (que tiene una clase A abstracta ), analizó el sistema existente y descubrió que va a tener algunos métodos que son casi similares a los métodos de la clase C concreta . Pero también descubrió que algunos métodos de la clase C concreta son demasiado específicos y desea imponer la implementación de esos métodos en las subclases concretas de la clase A abstracta .
Por lo tanto, le permite elegir de forma selectiva qué métodos reutilizar y cuáles no reutilizar.
Anteriormente aprendí que la clase abstracta puede extender la clase concreta. Aunque no veo la razón de esto por parte de los diseñadores de JAVA, pero está bien. También aprendí que la clase abstracta que extiende la clase concreta puede hacer que los métodos anulados sean abstractos. ¿Por qué? ¿Se puede proporcionar un caso de uso donde sea útil? Estoy tratando de aprender patrones de diseño y no quiero perderme nada.
Aquí está el ejemplo:
public class Foo
{
public void test()
{
}
}
public abstract class Bar extends Foo
{
@Override
public abstract void test();
}
Esta flexibilidad es especialmente útil cuando un sistema evoluciona y no queremos alterar el código existente.
Un ejemplo simple que podría pensar es considerar una clase MSDocReader . Esta clase es parte del sistema heredado y muchas otras aplicaciones dependen de esto.
Ahora los requisitos cambian. Tenemos que escribir clases para leer archivos docx, ppt e incluso archivos xsl.
La clase MSDocReader contiene métodos que pueden reutilizarse, como obtener el tamaño del archivo en KB, conectarse al marco .Net (si no estoy equivocado :-))
Ahora, utilizando esta disposición, podemos escribir una clase absract AbstractMSFileReader que contendrá todos los métodos que se utilizan en MSDocReader . Pero esta clase tendrá el método de lectura como abstracto.
La razón es que queremos forzar a los desarrolladores a usar su propia versión del método de lectura. (No deberíamos usar la herencia, ya que la herencia indica claramente que el método de subclase ampliará la funcionalidad del método principal. Leer un archivo doc y leer un archivo excel son dos cosas diferentes y no están dentro de la misma jerarquía).
Y puede argumentar que podemos hacer una clase abstracta y hacer que la clase MSDocReader extienda esa clase abstracta. Pero puede suceder que la clase MSDocReader pueda estar extendiendo a otra clase y, como Java no admite la herencia múltiple, puede crear problemas.
Esto resulta útil si tengo un conjunto de clases para las que quiero una implementación predeterminada de test()
(para que puedan extenderse desde Foo
), y un subconjunto de esas clases que deseo forzar para proporcionar su propia implementación (en cuyo caso Haciéndolo abstracto en la subclase haría cumplir esto.)
Por supuesto, la forma alternativa en este ejemplo sería declarar test()
abstract en la clase de nivel superior en lugar de en la subclase, y eso es lo que haría normalmente, pero hay casos en los que se satisface la relación de herencia es-una significa que ocasionalmente tiene más sentido desde una perspectiva de diseño al hacerlo de esta manera. Es raro, pero a veces lo ves.
Además, aunque sea un caso especial, recuerde que todas las clases extienden implícitamente el Object
menos que se especifique lo contrario. Entonces, si incluyes este caso, ¡las clases abstractas que se extienden a clases concretas no son tan inusuales después de todo!
Para hacer la clase que extendió su clase (resumen) para proporcionar un tipo específico de implementación.
Por ejemplo:
- clase abstracta
- ClassB extiende ClassB - Proporciona implementación específica de métodos abstractos definidos en ClassA
Si hace que el método de test
abstracto, obliga a cualquier persona que se derive de la clase Bar
proporcionar una implementación del método.
Si elimina el método abstracto de la clase Bar
, cualquiera que se derive de Bar
no tendría que implementar el método de test
, ya que Foo
ya proporciona una implementación (vacía).