Este enunciado ha sido analizado por nuestros especialistas para que tengas la seguridad de la veracidad de este post.
Solución:
Está totalmente bien cuando una clase abstracta extiende otra clase abstracta. Solo significa que detalles el comportamiento de la nueva clase establecido sobre el comportamiento de la vieja clase. Pero todavía no es un objeto completo para usar, porque aún se desconoce parte de su comportamiento.
En analogía con el mundo real.
Imagina que tienes una clase. Vehicle. Puede ser cualquier vehículo: coche, avión, autobús, bicicleta, lo que sea. Esta es tu clase abstracta. ¿Puedes usarlo ahora? No, porque no sabes si tienes que pisar los pedales o girar el volante.
Ahora crea otra clase, digamos, Car extends Vehicle. ¿Puedes usarlo ahora? Probablemente, pero aún no sabes si es un camión o un automóvil de pasajeros. Pero ya sabes que tiene volante.
Y finalmente, cuando cree una clase más, diga, MySuperPassengerCar extends Car sabes exactamente qué objeto es, cómo se puede usar y qué métodos tiene.
La clase abstracta define métodos abstractos. Cualquier clase que extienda otra clase mejora la superclase al agregar más comportamiento. Si la clase secundaria es abstracta, puede agregar algún comportamiento abstracto.
Los métodos abstractos son como contratos. El otro código puede consumir el código existente y puede depender de él. La clase concreta está obligada a seguir el contrato proporcionando la implementación.
Veámoslo con un ejemplo a continuación.
public abstract class SuperAbstract
public void nonAbstract()
// some code
public abstract void contract();
public abstract class SubAbstract extends SuperAbstract
public void additionalNonAbstract()
// some code
public abstract void additionalContract();
}
public class Concrete extends SubAbstract
public void contract()
// implementation
public void additionalContract()
//implementation
// although below is allowed and sometimes when we use an external library then this is one of the way but still this is not a good practice.
// dependencies should be on abstractions only and not on concrete implementation
public abstract class AnotherAbstract extends Concrete
public void someMethod()
//some code
public abstract void oneMoreContract();
public class ConcreteA extends AnotherAbstract
public void oneMoreContract()
//some implementation
Ahora tenga en cuenta que en total hemos definido 3 contratos y ConcreteA tiene todas las implementaciones. También tenga en cuenta que como Concrete proporciona implementaciones para métodos contract y additionalContract por lo tanto, esas implementaciones son heredadas por ConcreteA
El código del consumidor puede depender fácilmente de la abstracción. Vamos a verlo en código de usuario (código de consumidor)
public class Consumer
public void m1(SuperAbstract c)
c.contract();
c.nonAbstract();
public void m2(AnotherAbstract c)
c.contract();
c.nonAbstract();
c.oneMoreContract();
c.additionalContract();
}
Ahora veamos el código de cableado que proporciona las dependencias.
public class Main
public static void main(String[] args)
Consumer c = new Consumer();
c.m1(new Concrete());
c.m1(new ConcreteA());
c.m2(new ConcreteA());
Si para ti ha resultado de ayuda este post, sería de mucha ayuda si lo compartes con otros entusiastas de la programación de esta manera contrubuyes a dar difusión a nuestro contenido.