Ejemplos específicos de clases abstractas en Java

¡Hola! En lecciones anteriores, conocimos las interfaces y descubrimos para qué sirven. El tema de hoy se hará eco del anterior. Hablemos de clases abstractas en Java.

Por qué las clases se llaman 'abstractas'

Probablemente recuerde lo que es 'abstracción', ya lo hemos repasado. :) Si lo olvidaste, no temas. Recuerda: es un principio de la programación orientada a objetos que dice que al diseñar clases y crear objetos, debemos identificar solo las propiedades principales de la entidad y descartar las secundarias. Por ejemplo, si estamos diseñando una SchoolTeacherclase, apenas necesitamos una propiedad de ' altura '. De hecho, esta propiedad es irrelevante para un profesor. Pero si estamos creando una BasketballPlayerclase, entonces el crecimiento sería una característica importante. Entonces escucha. Una clase abstractaes tan abstracto como parece: un "espacio en blanco" inacabado para un grupo de clases futuras. El espacio en blanco no se puede utilizar tal como está. Es demasiado 'crudo'. Pero describe cierto estado y comportamiento general que tendrán las futuras clases que hereden la clase abstracta.

Ejemplos de clases abstractas de Java

Considere un ejemplo simple con automóviles:

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public abstract void gas();

   public abstract void brake();

   public String getModel() {
       return model;
   }

   public void setModel(String model) {
       this.model = model;
   }

   public String getColor() {
       return color;
   }

   public void setColor(String color) {
       this.color = color;
   }

   public int getMaxSpeed() {
       return maxSpeed;
   }

   public void setMaxSpeed(int maxSpeed) {
       this.maxSpeed = maxSpeed;
   }
}

Así es como se ve la clase abstracta más simple. Como puede ver, no es nada especial :) ¿Por qué lo necesitaríamos? En primer lugar, describe nuestra entidad requerida, un automóvil, de la manera más abstracta posible. Hay una razón por la que estamos usando la palabra abstracto . En el mundo real, no hay 'coches abstractos'. Hay camiones, autos de carrera, sedanes, cupés y SUV. Nuestra clase abstracta es simplemente un "modelo" que usaremos más adelante para crear clases de autos.

public class Sedan extends Car {

   @Override
   public void gas() {
       System.out.println("The sedan is accelerating!");
   }

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

Esto es muy similar a lo que hablamos en las lecciones sobre herencia. Pero en esas lecciones, teníamos una clase de Auto y sus métodos no eran abstractos. Pero esa solución tiene una serie de inconvenientes que se corrigen en las clases abstractas. En primer lugar, no puede crear una instancia de una clase abstracta :

public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Error! The Car class is abstract!
   }
}

Los creadores de Java diseñaron específicamente esta 'característica'. Una vez más, como recordatorio: una clase abstracta es solo un modelo para futuras clases 'normales' . No necesitas copias del plano, ¿verdad? Y no crea instancias de una clase abstracta :) Pero si la Carclase no fuera abstracta, podríamos crear fácilmente instancias de ella:

public class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       // Some logic
   }

    public void brake() {
       // Some logic
   }
}


public class Main {

   public static void main(String[] args) {

       Car car = new Car(); // Everything is fine. A car is created.
   }
}

Ahora nuestro programa tiene una especie de auto incomprensible: no es un camión, ni un auto de carrera, ni un sedán, y no está del todo claro qué es. Este es el mismo 'coche abstracto' que no existe en la naturaleza. Podemos dar el mismo ejemplo usando animales. Imagínese si Animallas clases ( animales abstractos ). No está claro qué tipo de animal es, a qué familia pertenece y qué características tiene. Sería extraño ver eso en su programa. No hay 'animales abstractos' en la naturaleza. Solo perros, gatos, zorros, topos, etc. Las clases abstractas nos liberan de los objetos abstractos. Nos dan el estado y el comportamiento básicos. Por ejemplo, todos los autos deben tener un modelo , un color y una velocidad máxima , y ​​usted debe poder aplicar elgas y freno . Eso es todo. Este es un plan abstracto general. A continuación, diseña las clases que necesita. Nota: dos métodos en la clase abstracta también se designan como abstractos y no tienen ninguna implementación. La razón es la misma: las clases abstractas no crean un comportamiento predeterminado para los autos abstractos. Simplemente indican lo que cada automóvil debería poder hacer. Sin embargo, si necesita un comportamiento predeterminado, puede implementar métodos en una clase abstracta. Java no prohíbe esto:

public abstract class Car {

   private String model;
   private String color;
   private int maxSpeed;

   public void gas() {
       System.out.println("Gas!");
   }

   public abstract void brake();

   // Getters and setters
}


public class Sedan extends Car {

   @Override
   public void brake() {
       System.out.println("The sedan is slowing down!");
   }

}

public class Main {

   public static void main(String[] args) {

       Sedan sedan = new Sedan();
       sedan.gas();
   }
}

Salida de la consola: "¡Gas!" Como puede ver, hemos implementado el primer método en la clase abstracta, y no el segundo. Como resultado, el Sedancomportamiento de nuestra clase se divide en dos partes: si llama al gas()método, la llamada 'sube' a la Carclase padre abstracta, pero anulamos el brake()método en la Sedanclase. Esto resulta ser muy conveniente y flexible. ¿Pero ahora nuestra clase no es tan abstracta ? Después de todo, la mitad de sus métodos están implementados. Esto es en realidad una característica muy importante: una clase es abstracta si al menos uno de sus métodos es abstracto. Uno de dos métodos, o al menos uno de mil métodos, no hace ninguna diferencia. Incluso podemos implementar todos los métodos y no dejar ninguno de ellos abstracto. Entonces sería una clase abstracta sin métodos abstractos. En principio esto es posible, y el compilador no generará errores, pero es mejor evitarlo: La palabra abstracto pierde su significado, y tus compañeros programadores se sorprenderán mucho :/ Al mismo tiempo, si un método está marcado con la palabra abstracto, cada clase secundaria debe implementarlo o declararlo como abstracto. De lo contrario, el compilador generará un error. Por supuesto, cada clase puede heredar solo una clase abstracta, por lo que en términos de herencia no hay diferencia entre clases ordinarias y abstractas. No importa si heredamos una clase abstracta o una ordinaria, solo puede haber una clase padre.

¿Por qué Java no tiene herencia múltiple de clases?

Ya dijimos que Java no tiene herencia múltiple, pero realmente no hemos explorado por qué. Tratemos de hacer eso ahora. El hecho es que si Java tuviera herencia múltiple, las clases secundarias no podrían decidir qué comportamiento específico deberían elegir. Supongamos que tenemos dos clases — Toastery NuclearBomb:

public class Toaster {


 public void on() {

       System.out.println("The toaster is on. Toast is being prepared!");
   }

   public void off() {

       System.out.println("The toaster is off!");
   }
}


public class NuclearBomb {

   public void on() {

       System.out.println("Boom!");
   }
}

Como puede ver, ambos tienen un on()método. Para una tostadora, comienza a tostar. Para una bomba nuclear, provoca una explosión. Ups: / Ahora imagina que decidiste (¡no me preguntes por qué!) crear algo intermedio. ¡Y así tienes una MysteriousDeviceclase! Este código, por supuesto, no funciona, y solo lo proporcionamos como un ejemplo 'pero podría ser':

public class MysteriousDevice extends Toaster, NuclearBomb {

   public static void main(String[] args) {

       MysteriousDevice mysteriousDevice = new MysteriousDevice();
       mysteriousDevice.on(); // So what should happen here? Do we get toast or a nuclear apocalypse?
   }
}

Echemos un vistazo a lo que tenemos. El misterioso dispositivo hereda simultáneamente Toaster y NuclearBomb. Ambos tienen on()métodos. Como resultado, si llamamos al on()método, no está claro cuál debe invocarse en el MysteriousDeviceobjeto. No hay forma de que el objeto pueda saberlo. Y para colmo: la bomba nuclear no tiene off()método, por lo que si no acertamos, será imposible desactivar el dispositivo. Es precisamente por esta 'confusión', donde el objeto no sabe qué comportamiento exhibir, que los creadores de Java abandonaron la herencia múltiple. Sin embargo, recordará que las clases de Java pueden implementar múltiples interfaces. Por cierto, en tus estudios, ¡ya te has encontrado con al menos una clase abstracta!

public abstract class Calendar implements Serializable, Cloneable, Comparable<Calendar>

Es tu viejo amigo, la Calendarclase. Es abstracto y tiene varios hijos. uno de ellos GregorianCalendares Ya lo usaste en las lecciones sobre fechas. :) Todo parece lo suficientemente claro. Solo hay una pregunta: ¿cuál es la diferencia fundamental entre las clases abstractas y las interfaces de todos modos? ¿Por qué agregaron ambos a Java en lugar de solo limitar el idioma a uno? Después de todo, eso habría sido totalmente adecuado. ¡Hablaremos de esto en la próxima lección ! Hasta entonces :)