Herencia
Considere un automóvil y un autobús. Son dos vehículos diferentes. Pero aún así, comparten algunas propiedades comunes como tener una dirección, frenos, engranajes, motor, etc.
Así que con el concepto de herencia, esto se puede representar de la siguiente manera ...
public class Vehicle {
private Driver driver;
private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections).
//You can define as many properties as you want here ...
}
Ahora una bicicleta ...
public class Bicycle extends Vehicle {
//You define properties which are unique to bicycles here ...
private Pedal pedal;
}
Y un auto ...
public class Car extends Vehicle {
private Engine engine;
private Door[] doors;
}
Eso es todo sobre herencia . Los usamos para clasificar objetos en formas básicas más simples y sus hijos como vimos anteriormente.
Clases abstractas
Las clases abstractas son objetos incompletos . Para entenderlo más, consideremos la analogía del vehículo una vez más.
Un vehículo puede ser conducido. ¿Derecha? Pero los diferentes vehículos se manejan de diferentes maneras ... Por ejemplo, no puede conducir un automóvil tal como conduce una bicicleta.
Entonces, ¿cómo representar la función de conducción de un vehículo? Es más difícil verificar qué tipo de vehículo es y conducirlo con su propia función; tendría que cambiar la clase de Conductor una y otra vez al agregar un nuevo tipo de vehículo.
Aquí viene el papel de las clases y métodos abstractos. Puede definir el método de unidad como abstracto para indicar que todos los elementos secundarios heredados deben implementar esta función.
Entonces, si modifica la clase de vehículo ...
//......Code of Vehicle Class
abstract public void drive();
//.....Code continues
La bicicleta y el automóvil también deben especificar cómo conducirlo. De lo contrario, el código no se compilará y se generará un error.
En resumen ... una clase abstracta es una clase parcialmente incompleta con algunas funciones incompletas, que los hijos herederos deben especificar.
Interfaces Las
interfaces son totalmente incompletas. No tienen ninguna propiedad. Solo indican que los hijos herederos son capaces de hacer algo ...
Supongamos que tiene diferentes tipos de teléfonos móviles con usted. Cada uno de ellos tiene diferentes formas de hacer diferentes funciones; Ej: llamar a una persona. El fabricante del teléfono especifica cómo hacerlo. Aquí los teléfonos móviles pueden marcar un número, es decir, se puede marcar. Representemos esto como una interfaz.
public interface Dialable {
public void dial(Number n);
}
Aquí el creador de Dialable define cómo marcar un número. Solo necesita darle un número para marcar.
// Makers define how exactly dialable work inside.
Dialable PHONE1 = new Dialable() {
public void dial(Number n) {
//Do the phone1's own way to dial a number
}
}
Dialable PHONE2 = new Dialable() {
public void dial(Number n) {
//Do the phone2's own way to dial a number
}
}
//Suppose there is a function written by someone else, which expects a Dialable
......
public static void main(String[] args) {
Dialable myDialable = SomeLibrary.PHONE1;
SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....
Mediante el uso de interfaces en lugar de clases abstractas, el escritor de la función que utiliza un Dialable no necesita preocuparse por sus propiedades. Ej: ¿Tiene una pantalla táctil o teclado de marcación? ¿Es un teléfono fijo o un teléfono móvil? Solo necesita saber si se puede marcar; ¿Hereda (o implementa) la interfaz Dialable?
Y lo más importante , si algún día cambias el Dialable por uno diferente
......
public static void main(String[] args) {
Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....
Puede estar seguro de que el código aún funciona perfectamente porque la función que usa el marcado no depende (y no puede) de los detalles que no sean los especificados en la interfaz Marcable. Ambos implementan una interfaz Dialable y eso es lo único que le importa a la función.
Los desarrolladores utilizan comúnmente las interfaces para garantizar la interoperabilidad (uso intercambiable) entre objetos, siempre que compartan una función común (al igual que puede cambiar a un teléfono fijo o móvil, en la medida en que solo necesita marcar un número). En resumen, las interfaces son una versión mucho más simple de clases abstractas, sin ninguna propiedad.
Además, tenga en cuenta que puede implementar (heredar) tantas interfaces como desee, pero solo puede extender (heredar) una sola clase principal.
Más información
Clases abstractas vs Interfaces
