¿Cuál es la diferencia entre una interfaz y una clase abstracta?

¿Cuál es exactamente la diferencia entre una interfaz y una clase abstracta?

Interfaces

Una interfaz es un contrato : la persona que escribe la interfaz dice, ” oye, acepto las cosas que se ven de esa manera “, y la persona que usa la interfaz dice ” OK, la clase que escribo se ve de esa manera “.

Una interfaz es un shell vacío . Solo hay firmas de los métodos, lo que implica que los métodos no tienen un cuerpo. La interfaz no puede hacer nada. Es solo un patrón.

Por ejemplo (pseudo código):

// I say all motor vehicles should look like this: interface MotorVehicle { void run(); int getFuel(); } // My team mate complies and writes vehicle looking that way class Car implements MotorVehicle { int fuel; void run() { print("Wrroooooooom"); } int getFuel() { return this.fuel; } } 

La implementación de una interfaz consume muy poca CPU, porque no es una clase, solo un montón de nombres, y por lo tanto no hay una búsqueda costosa para hacer. Es genial cuando es importante, como en los dispositivos integrados.


Clases abstractas

Las clases abstractas, a diferencia de las interfaces, son clases. Son más caros de usar, porque hay una búsqueda que hacer cuando heredas de ellos.

Las clases abstractas se parecen mucho a las interfaces, pero tienen algo más: puede definir un comportamiento para ellas. Se trata más de una persona que dice: “estas clases deberían verse así, y tienen eso en común, ¡así que complete los espacios en blanco!”.

Por ejemplo:

 // I say all motor vehicles should look like this: abstract class MotorVehicle { int fuel; // They ALL have fuel, so lets implement this for everybody. int getFuel() { return this.fuel; } // That can be very different, force them to provide their // own implementation. abstract void run(); } // My teammate complies and writes vehicle looking that way class Car extends MotorVehicle { void run() { print("Wrroooooooom"); } } 

Implementación

Si bien se supone que las clases abstractas y las interfaces son conceptos diferentes, las implementaciones hacen que esa statement a veces sea falsa. A veces, ni siquiera son lo que crees que son.

En Java, esta regla se aplica con fuerza, mientras que en PHP, las interfaces son clases abstractas sin método declarado.

En Python, las clases abstractas son más un truco de progtwigción que puedes obtener del módulo ABC y en realidad está utilizando metaclases y, por lo tanto, clases. Y las interfaces están más relacionadas con el tipado de patos en este idioma y es una mezcla entre convenciones y métodos especiales que llaman descriptores (los métodos __method__).

Como es habitual con la progtwigción, hay teoría, práctica y práctica en otro idioma 🙂

Las diferencias técnicas clave entre una clase abstracta y una interfaz son:

  • Las clases abstractas pueden tener constantes, miembros, trozos de métodos (métodos sin cuerpo) y métodos definidos , mientras que las interfaces solo pueden tener constantes y trozos de métodos .

  • Los métodos y los miembros de una clase abstracta se pueden definir con cualquier visibilidad , mientras que todos los métodos de una interfaz se deben definir como public (se definen como públicos por defecto).

  • Al heredar una clase abstracta, una clase hija concreta debe definir los métodos abstractos , mientras que una clase abstracta puede extender otra clase abstracta y los métodos abstractos de la clase principal no tienen que definirse.

  • De manera similar, una interfaz que extiende otra interfaz no es responsable de implementar métodos desde la interfaz principal. Esto se debe a que las interfaces no pueden definir ninguna implementación.

  • Una clase hija solo puede extender una sola clase (abstracta u concreta), mientras que una interfaz puede extenderse o una clase puede implementar múltiples otras interfaces .

  • Una clase infantil puede definir métodos abstractos con la misma visibilidad o menos restrictiva , mientras que una clase que implementa una interfaz debe definir los métodos con la misma visibilidad (pública).

Una interfaz contiene solo la definición / firma de funcionalidad, y si tenemos alguna funcionalidad común, así como firmas comunes, entonces necesitamos usar una clase abstracta. Al usar una clase abstracta, podemos proporcionar tanto el comportamiento como la funcionalidad al mismo tiempo. Otro desarrollador que hereda clase abstracta puede usar esta funcionalidad fácilmente, ya que solo necesitarían completar los espacios en blanco.

enter image description here

Tomado de:

http://www.dotnetbull.com/2011/11/difference-between-abstract-class-and.html

http://www.dotnetbull.com/2011/11/what-is-abstract-class-in-c-net.html http://www.dotnetbull.com/2011/11/what-is-interface-in -c-net.html

Puede encontrar una explicación aquí: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter-Pattern.htm

Una clase abstracta es una clase implementada solo parcialmente por el progtwigdor. Puede contener uno o más métodos abstractos. Un método abstracto es simplemente una definición de función que sirve para decirle al progtwigdor que el método debe implementarse en una clase hija.

Una interfaz es similar a una clase abstracta; de hecho, las interfaces ocupan el mismo espacio de nombres que las clases y las clases abstractas. Por ese motivo, no puede definir una interfaz con el mismo nombre que una clase. Una interfaz es una clase completamente abstracta; ninguno de sus métodos está implementado y, en lugar de una clase de subclasificación a partir de él, se dice que implementa esa interfaz.

De todos modos, encuentro que esta explicación de interfaces es algo confusa. Una definición más común es: una interfaz define un contrato que las clases de implementación deben cumplir. Una definición de interfaz consiste en firmas de miembros públicos, sin ningún código de implementación.

Algunas diferencias importantes:

En forma de una tabla:

Diferencia

Como dijo Joe desde javapapers :

1. La principal diferencia es que los métodos de una interfaz Java son implícitamente abstractos y no pueden tener implementaciones. Una clase abstracta de Java puede tener métodos de instancia que implemente un comportamiento predeterminado.

2. Las variables declaradas en una interfaz Java son predeterminadas por defecto. Una clase abstracta puede contener variables no finales.

3. Los miembros de una interfaz Java son públicos por defecto. Una clase abstracta de Java puede tener los sabores habituales de los miembros de la clase como privado, protegido, etc.

4. La interfaz Java debe implementarse usando la palabra clave “implements”; Una clase abstracta de Java debería extenderse usando la palabra clave “extends”.

5. Una interfaz puede extender solo otra interfaz Java, una clase abstracta puede extender otra clase Java e implementar múltiples interfaces Java.

6. Una clase Java puede implementar múltiples interfaces pero puede extender solo una clase abstracta.

7. La interfaz es absolutamente abstracta y no puede ser instanciada; Una clase abstracta de Java tampoco puede crearse una instancia, pero puede invocarse si existe una main ().

8. En comparación con las clases abstractas de Java, las interfaces de Java son lentas ya que requieren una indirección adicional.

No quiero resaltar las diferencias, que ya se han dicho en muchas respuestas (con respecto a los modificadores finales públicos estáticos para variables en la interfaz y el soporte para métodos privados protegidos en clases abstractas)

En términos simples, me gustaría decir:

interfaz: implementar un contrato por múltiples objetos no relacionados

clase abstracta: implementar el mismo o diferente comportamiento entre múltiples objetos relacionados

De la documentación de Oracle

Considere usar clases abstractas si:

  1. Desea compartir el código entre varias clases estrechamente relacionadas.
  2. Espera que las clases que amplían su clase abstracta tengan muchos métodos o campos comunes, o que requieran modificadores de acceso que no sean públicos (como protegidos y privados).
  3. Desea declarar campos no estáticos o no finales.

Considere usar interfaces si:

  1. Esperas que las clases no relacionadas implementen tu interfaz. Por ejemplo, muchos objetos no relacionados pueden implementar una interfaz Serializable .
  2. Desea especificar el comportamiento de un tipo de datos particular, pero no le preocupa quién implementa su comportamiento.
  3. Desea aprovechar la herencia múltiple de tipo.

clase abstracta establece “es una” relación con clases concretas. la interfaz proporciona la capacidad “tiene una” para las clases.

Si está buscando Java como lenguaje de progtwigción, aquí hay algunas actualizaciones más:

Java 8 ha reducido la brecha entre la interface y las clases abstract en cierta medida al proporcionar una función de método default . Una interfaz que no tiene una implementación para un método ya no es válida ahora.

Consulte esta página de documentación para más detalles.

Eche un vistazo a esta pregunta SE para ejemplos de códigos para comprender mejor.

¿Cómo debería haber explicado la diferencia entre una interfaz y una clase abstracta?

El punto principal es que:

  • El resumen está orientado a objetos . Ofrece los datos básicos que un ‘objeto’ debería tener y / o funciones que debería poder hacer. Se ocupa de las características básicas del objeto: qué tiene y qué puede hacer. Por lo tanto, los objetos que heredan de la misma clase abstracta comparten las características básicas (generalización).
  • La interfaz está orientada a la funcionalidad . Define las funcionalidades que un objeto debería tener. Independientemente de qué objeto sea, siempre que pueda hacer estas funcionalidades, que se definen en la interfaz, está bien. Ignora todo lo demás. Un objeto / clase puede contener varias (grupos de) funcionalidades; por lo tanto, es posible que una clase implemente interfaces múltiples.

Estoy construyendo un edificio de 300 pisos

La interfaz del proyecto del edificio

  • Por ejemplo, Servlet (I)

Edificio construido hasta 200 pisos – parcialmente terminado — abstracto

  • Implementación parcial, por ejemplo, servlet genérico y HTTP

Construcción de edificios completada de hormigón

  • Implementación completa, por ejemplo, servlet propio

Interfaz

  • No sabemos nada sobre la implementación, solo requisitos. Podemos ir por una interfaz.
  • Todos los métodos son públicos y abstractos por defecto
  • Es una clase abstracta 100% pura
  • Si declaramos pública no podemos declarar privada y protegida
  • Si declaramos el resumen no podemos declarar final, estático, sincronizado, strictfp y nativo
  • Cada interfaz tiene público, estático y final
  • La serialización y transitorios no son aplicables, porque no podemos crear una instancia en la interfaz
  • No volátil porque es final
  • Cada variable es estática
  • Cuando declaramos una variable dentro de una interfaz, necesitamos inicializar las variables mientras declaramos
  • Instancia y locking estático no permitidos

Abstracto

  • Implementación parcial
  • Tiene un método abstracto. Además, usa concreto
  • Sin restricciones para modificadores de métodos de clase abstractos
  • Sin restricciones para modificadores de variables de clase abstractas
  • No podemos declarar otros modificadores excepto abstractos
  • Sin restricción para inicializar variables

Tomado del sitio web de DurgaJobs

Cuando desee proporcionar un comportamiento polimórfico en una jerarquía de herencia, use clases abstractas.

Cuando desee comportamiento polimórfico para clases que no están relacionadas, use una interfaz.

Vamos a trabajar en esta pregunta de nuevo:

Lo primero que debe saber es que 1/1 y 1 * 1 tienen el mismo resultado, pero eso no significa que la multiplicación y la división sean iguales. Obviamente, mantienen una buena relación, pero tengan en cuenta que ambos son diferentes.

Señalaré las principales diferencias, y el rest ya se ha explicado:

Las clases abstractas son útiles para modelar una jerarquía de clases. A primera vista de cualquier requisito, somos parcialmente claros en lo que se construye exactamente , pero sabemos qué construir. Y entonces tus clases abstractas son tus clases base.

Las interfaces son útiles para dejar que otras jerarquías o clases sepan lo que soy capaz de hacer. Y cuando dices que soy capaz de algo, debes tener esa capacidad. Las interfaces marcarán como obligatorio para una clase implementar las mismas funcionalidades.

Es bastante simple en realidad.

Puede pensar en una interfaz como una clase que solo puede tener métodos abstractos y nada más.

Por lo tanto, una interfaz solo puede “declarar” y no definir el comportamiento que desea que tenga la clase.

Una clase abstracta le permite hacer tanto declarar (utilizando métodos abstractos) como definir (utilizando implementaciones completas de métodos) el comportamiento que desea que tenga la clase.

Y una clase regular solo le permite definir, no declarar, el comportamiento / acciones que desea que tenga la clase.

Una última cosa,

En Java, puede implementar múltiples interfaces, pero solo puede extender una (clase abstracta o clase) …

Esto significa que la herencia del comportamiento definido está restringida para permitir solo uno por clase … es decir, si desea una clase que encapsule el comportamiento de las Clases A, B y C, deberá hacer lo siguiente: La Clase A se extiende B, la Clase C se extiende A .. es un poco redondo sobre la forma de tener herencia múltiple …

Las interfaces, por otro lado, podrían simplemente hacer: la interfaz C implementa A, B

Así que, en efecto, Java admite la herencia múltiple solo en “comportamiento declarado”, es decir, interfaces, y solo una herencia única con un comportamiento definido … a menos que hagas la ronda sobre la forma que describí …

Espero que tenga sentido.

La única diferencia es que uno puede participar en herencia múltiple y otros no.

La definición de una interfaz ha cambiado con el tiempo. ¿Crees que una interfaz solo tiene declaraciones de métodos y son solo contratos? ¿Qué pasa con las variables finales estáticas y qué pasa con las definiciones predeterminadas después de Java 8?

Las interfaces se introdujeron en Java debido al problema del diamante con herencia múltiple y eso es lo que realmente intentan hacer.

Las interfaces son las construcciones que se crearon para salirse con la suya con el problema de la herencia múltiple y pueden tener métodos abstractos, definiciones predeterminadas y variables finales estáticas.

Consulte ¿Por qué Java permite variables finales estáticas en las interfaces cuando solo pretenden ser contratos? .

La comparación de la interfaz frente a la clase abstracta es incorrecta. En su lugar, debe haber otras dos comparaciones: 1) interfaz vs. clase y 2) clase abstracta vs. clase final .

Interfaz vs clase

La interfaz es un contrato entre dos objetos. Por ejemplo, soy cartero y tú eres un paquete para entregar. Espero que conozca su dirección de entrega. Cuando alguien me da un paquete, debe conocer su dirección de entrega:

 interface Package { String address(); } 

La clase es un grupo de objetos que obedecen el contrato. Por ejemplo, soy una caja del grupo “Caja” y obedezco el contrato requerido por el cartero. Al mismo tiempo obedezco otros contratos:

 class Box implements Package, Property { @Override String address() { return "5th Street, New York, NY"; } @Override Human owner() { // this method is part of another contract } } 

Resumen vs Final

La clase abstracta es un grupo de objetos incompletos. No se pueden usar porque pierden algunas partes. Por ejemplo, soy un cuadro abstracto con reconocimiento de GPS: sé cómo verificar mi posición en el mapa:

 abstract class GpsBox implements Package { @Override public abstract String address(); protected Coordinates whereAmI() { // connect to GPS and return my current position } } 

Esta clase, si es heredada / extendida por otra clase, puede ser muy útil. Pero por sí solo, es inútil, ya que no puede tener objetos. Las clases abstractas pueden ser elementos de construcción de las clases finales.

La clase final es un grupo de objetos completos, que se pueden usar, pero no se pueden modificar. Ellos saben exactamente cómo trabajar y qué hacer. Por ejemplo, soy una caja que siempre va a la dirección especificada durante su construcción:

 final class DirectBox implements Package { private final String to; public DirectBox(String addr) { this.to = addr; } @Override public String address() { return this.to; } } 

En la mayoría de los lenguajes, como Java o C ++, es posible tener solo una clase , ni abstracta ni final. Tal clase puede ser heredada y puede ser instanciada. Sin embargo, no creo que esto esté estrictamente en línea con el paradigma orientado a objetos.

De nuevo, comparar interfaces con clases abstractas no es correcto.

En resumen, las diferencias son las siguientes:

Diferencias sintácticas entre interfaz y clase abstracta :

  1. Los métodos y los miembros de una clase abstracta pueden tener cualquier visibilidad. Todos los métodos de una interfaz deben ser públicos . // Ya no es cierto desde Java 9
  2. Una clase infantil concreta de una clase abstracta debe definir todos los métodos abstractos. Una clase infantil abstracta puede tener métodos abstractos. Una interfaz que extiende otra interfaz no necesita proporcionar implementación predeterminada para métodos heredados de la interfaz principal.
  3. Una clase infantil solo puede extender una sola clase. Una interfaz puede extender múltiples interfaces. Una clase puede implementar múltiples interfaces.
  4. Una clase infantil puede definir métodos abstractos con la misma o menos visibilidad restrictiva, mientras que la clase que implementa una interfaz debe definir todos los métodos de interfaz como públicos.
  5. Las clases abstractas pueden tener constructores pero no interfaces .
  6. Las interfaces de Java 9 tienen métodos privados estáticos.

En interfaces ahora:

public static – apoyado
public abstract – apoyado
public default : compatible
private static – compatible
private abstract – error de comstackción
private default – error de comstackción
private – apoyado

Interfaz: girar (girar a la izquierda, girar a la derecha)

Clase abstracta: Rueda.

Clase: volante, deriva de la rueda, expone la interfaz de giro

Una es para categorizar el comportamiento que se puede ofrecer en una amplia gama de cosas, la otra es para modelar una ontología de las cosas.

No es realmente la respuesta a la pregunta original, pero una vez que tenga la respuesta a la diferencia entre ellos, ingresará el dilema de cuándo usar cada dilema: ¿ Cuándo usar interfaces o clases abstractas? Cuándo usar ambos?

Tengo conocimiento limitado de OOP, pero ver las interfaces como un equivalente de un adjetivo en gramática me ha funcionado hasta ahora (¡corríjanme si este método es falso!). Por ejemplo, los nombres de interfaz son como atributos o capacidades que puede proporcionar a una clase, y una clase puede tener muchos de ellos: ISerializable, ICountable, IList, ICacheable, IHappy, …

Si tiene algunos métodos comunes que pueden ser utilizados por múltiples clases, vaya a clases abstractas. De lo contrario, si desea que las clases sigan un modelo definido, vaya a las interfaces.

Los siguientes ejemplos demuestran esto.

Clase abstracta en Java:

 abstract class animals { // They all love to eat. So let's implement them for everybody void eat() { System.out.println("Eating..."); } // The make different sounds. They will provide their own implementation. abstract void sound(); } class dog extends animals { void sound() { System.out.println("Woof Woof"); } } class cat extends animals { void sound() { System.out.println("Meoww"); } } 

Lo que sigue es una implementación de la interfaz en Java:

 interface Shape { void display(); double area(); } class Rectangle implements Shape { int length, width; Rectangle(int length, int width) { this.length = length; this.width = width; } @Override public void display() { System.out.println("****\n* *\n* *\n****"); } @Override public double area() { return (double)(length*width); } } class Circle implements Shape { double pi = 3.14; int radius; Circle(int radius) { this.radius = radius; } @Override public void display() { System.out.println("O"); // :P } @Override public double area() { return (double)((pi*radius*radius)/2); } } 

Algunos puntos clave importantes en pocas palabras:

  1. Las variables declaradas en la interfaz de Java son predeterminadas por defecto. Las clases abstractas pueden tener variables no finales.

  2. Las variables declaradas en la interfaz Java son por defecto estáticas. Las clases abstractas pueden tener variables no estáticas.

  3. Los miembros de una interfaz Java son públicos por defecto. Una clase abstracta de Java puede tener los sabores habituales de los miembros de la clase como privado, protegido, etc.

La herencia se usa con dos propósitos:

  • Permitir que un objeto considere los miembros de datos de tipo parental y las implementaciones de métodos como propios.

  • Permitir que una referencia a un objeto de un tipo sea utilizada por un código que espera una referencia al objeto supertipo.

En los lenguajes / marcos que soportan la herencia múltiple generalizada, a menudo hay poca necesidad de clasificar un tipo como una “interfaz” o una “clase abstracta”. Sin embargo, los lenguajes y marcos populares permitirán que un tipo considere los miembros de datos de otro tipo o las implementaciones de métodos como propios aunque permitan que un tipo sea sustituible por un número arbitrario de otros tipos.

Las clases abstractas pueden tener miembros de datos e implementaciones de métodos, pero solo pueden ser heredadas por clases que no heredan de ninguna otra clase. Las interfaces casi no imponen restricciones a los tipos que las implementan, pero no pueden incluir miembros de datos o implementaciones de métodos.

Hay momentos en los que es útil que los tipos sean sustituibles por muchas cosas diferentes; hay otras ocasiones en que es útil que los objetos consideren los miembros de datos de tipo parental y las implementaciones de métodos como propios. Hacer una distinción entre interfaces y clases abstractas permite que cada una de esas habilidades se use en los casos en que sea más relevante.

Puntos clave:

  • La clase abstracta puede tener propiedad, Campos de datos, Métodos (completo / incompleto) ambos.
  • Si el método o las Propiedades definen en palabra clave abstracta que debe sobrescribirse en la clase derivada. (Su trabajo es una funcionalidad estrechamente acoplada)
  • Si define la palabra clave abstracta para el método o las propiedades en la clase abstracta, no puede definir el cuerpo del método y obtener / establecer el valor de las propiedades y debe anular en la clase derivada.
  • La clase abstracta no admite herencia múltiple.
  • La clase abstracta contiene constructores.
  • Una clase abstracta puede contener modificadores de acceso para los subs, funciones, propiedades.
  • Solo el miembro completo de la clase abstracta puede ser estático.
  • Una interfaz solo puede heredar de otra interfaz y no puede heredar de una clase abstracta, donde una clase abstracta puede heredar de otra clase abstracta u otra.

Ventaja:

  • Es un tipo de contrato que obliga a todas las subclases a mantener las mismas jerarquías o estándares.
  • Si varias implementaciones son del mismo tipo y usan un comportamiento o estado común, entonces es mejor usar la clase abstracta.
  • Si agregamos un nuevo método a una clase abstracta, entonces tenemos la opción de proporcionar una implementación predeterminada y, por lo tanto, todo el código existente podría funcionar correctamente.
  • Permite una ejecución más rápida que la interfaz. (La interfaz requiere más tiempo para encontrar el método real en las clases correspondientes).
  • Se puede usar para un acoplamiento apretado y poco apretado.

encuentre los detalles aquí … http://pradeepatkari.wordpress.com/2014/11/20/interface-and-abstract-class-in-c-oops/

La forma más sencilla de resumirlo es que una interface es:

  1. Completamente abstracto, aparte de static métodos default y static ; si bien tiene definiciones (firmas de métodos + implementaciones) para métodos static y default , solo tiene declaraciones (firmas de métodos) para otros métodos.
  2. Sujeto a reglas más flexibles que las clases (una clase puede implementar múltiples interface , y una interface puede heredar de múltiples interface ). Todas las variables son implícitamente constantes, ya sea que estén especificadas como public static final o no. Todos los miembros son implícitamente public , ya sea que se especifiquen como tales o no.
  3. Generalmente se utiliza como garantía de que la clase implementadora tendrá las características especificadas y / o será compatible con cualquier otra clase que implemente la misma interfaz.

Mientras tanto, una clase abstract es:

  1. Cualquier lugar desde completamente abstracto hasta completamente implementado, con una tendencia a tener uno o más métodos abstract . Puede contener tanto declaraciones como definiciones, con declaraciones marcadas como abstract .
  2. Una clase completa y sujeta a las reglas que rigen otras clases (solo puede heredar de una clase), con la condición de que no pueda ser instanciada (porque no hay garantía de que esté completamente implementada). Puede tener variables de miembros no constantes. Puede implementar el control de acceso de miembro, restringir a los miembros como paquete protected , private o privado (no especificado).
  3. Generalmente se usa para proporcionar la mayor parte de la implementación que puedan compartir múltiples subclases, o para proporcionar la mayor parte de la implementación que el progtwigdor puede proporcionar.

O bien, si queremos resumirlo en una sola oración: una interface es lo que tiene la clase implementadora, pero una clase abstract es la subclase.

Many junior developers make the mistake of thinking of interfaces, abstract and concrete classes as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: “I” . When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.

Interfaces and abstract classes, although apparently similar from a technical point of view, have completely different meanings and purposes.

Resumen

  1. An interface defines a contract that some implementation will fulfill for you .

  2. An abstract class provides a default behavior that your implementation can reuse.

Alternative summary

  1. An interface is for defining public APIs
  2. An abstract class is for internal use, and for defining SPIs

On the importance of hiding implementation details

A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you’re going to use them. When you’re trying to squeeze performance out of a list that you’re heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you’re instantiating.

On the other hand, high level users of a list don’t really care how it is actually implemented, and they should be insulated from these details. Let’s imagine that Java didn’t expose the List interface, but only had a concrete List class that’s actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible… But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn’t be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it’s important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.

An abstract class is in the middle between interfaces and concrete classes. It is supposed to help implementations share common or boring code. For example, AbstractCollection provides basic implementations for isEmpty based on size is 0, contains as iterate and compare, addAll as repeated add , and so on. This lets implementations focus on the crucial parts that differentiate between them: how to actually store and retrieve data.

APIs versus SPIs

Interfaces are low-cohesion gateways between different parts of code. They allow libraries to exist and evolve without breaking every library user when something changes internally. It’s called Application Programming Interface , not Application Programming Classes. On a smaller scale, they also allow multiple developers to collaborate successfully on large scale projects, by separating different modules through well documented interfaces.

Abstract classes are high-cohesion helpers to be used when implementing an interface, assuming some level of implementation details. Alternatively, abstract classes are used for defining SPIs, Service Provider Interfaces.

The difference between an API and an SPI is subtle, but important: for an API, the focus is on who uses it, and for an SPI the focus is on who implements it.

Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classes are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.

A note on Java 8 and default methods

Although Java 8 introduced default methods for interfaces, which makes the line between interfaces and abstract classes even blurrier, this wasn’t so that implementations can reuse code, but to make it easier to change interfaces that serve both as an API and as an SPI (or are wrongly used for defining SPIs instead of abstract classes).

Which one to use?

  1. Is the thing supposed to be publicly used by other parts of the code, or by other external code? Add an interface to it to hide the implementation details from the public abstract contract, which is the general behavior of the thing.
  2. Is the thing something that’s supposed to have multiple implementations with a lot of code in common? Make both an interface and an abstract, incomplete implementation.
  3. Is there ever going to be only one implementation, and nobody else will use it? Just make it a concrete class.
    1. “ever” is long time, you could play it safe and still add an interface on top of it.

A corollary: the other way around is often wrongly done: when using a thing , always try to use the most generic class/interface that you actually need. In other words, don’t declare your variables as ArrayList theList = new ArrayList() , unless you actually have a very strong dependency on it being an array list, and no other type of list would cut it for you. Use List theList = new ArrayList instead, or even Collection theCollection = new ArrayList if the fact that it’s a list, and not any other type of collection doesn’t actually matter.

By definition, interfaces cannot have an implementation for any methods, and member variables cannot be initialized.

However, abstract classes can have methods implementated and member variables initialized.

Use abstract classes when you expect changes in your contract, ie, say in future you might need to add a new method.

In this situation, if you decide to use an interface, when the interface is changed to include interface, your application will break when you dumped the new interface dll.

To read in detail, visit difference between abstract class and a interface

I’d like to add one more difference which makes sense. For example, you have a framework with thousands of lines of code. Now if you want to add a new feature throughout the code using a method enhanceUI(), then it’s better to add that method in abstract class rather in interface. Because, if you add this method in an interface then you should implement it in all the implemented class but it’s not the case if you add the method in abstract class.

Differences between abstract class and interface on behalf of real implementation.

Interface : It is a keyword and it is used to define the template or blue print of an object and it forces all the sub classes would follow the same prototype,as for as implementation, all the sub classes are free to implement the functionality as per it’s requirement.

Some of other use cases where we should use interface.

Communication between two external objects(Third party integration in our application) done through Interface here Interface works as Contract.

Abstract Class: Abstract,it is a keyword and when we use this keyword before any class then it becomes abstract class.It is mainly used when we need to define the template as well as some default functionality of an object that is followed by all the sub classes and this way it removes the redundant code and one more use cases where we can use abstract class , such as we want no other classes can directly instantiate an object of the class, only derived classes can use the functionality.

Example of Abstract Class:

  public abstract class DesireCar { //It is an abstract method that defines the prototype. public abstract void Color(); // It is a default implementation of a Wheel method as all the desire cars have the same no. of wheels. // and hence no need to define this in all the sub classes in this way it saves the code duplicasy public void Wheel() { Console.WriteLine("Car has four wheel"); } } **Here is the sub classes:** public class DesireCar1 : DesireCar { public override void Color() { Console.WriteLine("This is a red color Desire car"); } } public class DesireCar2 : DesireCar { public override void Color() { Console.WriteLine("This is a red white Desire car"); } } 

Example Of Interface:

  public interface IShape { // Defines the prototype(template) void Draw(); } // All the sub classes follow the same template but implementation can be different. public class Circle : IShape { public void Draw() { Console.WriteLine("This is a Circle"); } } public class Rectangle : IShape { public void Draw() { Console.WriteLine("This is a Rectangle"); } } 

You can find clear difference between interface and abstract class.

Interfaz

  • Interface only contains abstract methods.
  • Force users to implement all methods when implements the interface.
  • Contains only final and static variables.
  • Declare using interface keyword.
  • All methods of an interface must be defined as public.
  • An interface can extend or a class can implement multiple other interfaces.

Abstract class

  • Abstract class contains abstract and non-abstract methods.

  • Does not force users to implement all methods when inherited the abstract class.

  • Contains all kinds of variables including primitive and non-primitive

  • Declare using abstract keyword.

  • Methods and members of an abstract class can be defined with any visibility.

  • A child class can only extend a single class (abstract or concrete).

enter image description here

Here is a very basic understanding over interface vs abstract class.

An abstract class is a class whose object cannot be created or a class which cannot be instantiated. An abstract method makes a class abstract. An abstract class needs to be inherited in order to override the methods that are declared in the abstract class. No restriction on access specifiers. An abstract class can have constructor and other concrete(non abstarct methods ) methods in them but interface cannot have.

An interface is a blueprint/template of methods.(eg. A house on a paper is given(interface house) and different architects will use their ideas to build it(the classes of architects implementing the house interface) . It is a collection of abstract methods , default methods , static methods , final variables and nested classes. All members will be either final or public , protected and private access specifiers are not allowed.No object creation is allowed. A class has to be made in order to use the implementing interface and also to override the abstract method declared in the interface. An interface is a good example of loose coupling(dynamic polymorphism/dynamic binding) An interface implements polymorphism and abstraction.It tells what to do but how to do is defined by the implementing class. For Eg. There’s a car company and it wants that some features to be same for all the car it is manufacturing so for that the company would be making an interface vehicle which will have those features and different classes of car(like Maruti Suzkhi , Maruti 800) will override those features(functions).

Why interface when we already have abstract class? Java supports only multilevel and hierarchal inheritance but with the help of interface we can implement multiple inheritance.

To give a simple but clear answer, it helps to set the context : you use both when you do not want to provide full implementations.

The main difference then is an interface has no implementation at all (only methods without a body) while abstract classes can have members and methods with a body as well, ie can be partially implemented.

In an interface all methods must be only definitions, not single one should be implemented.

But in an abstract class there must an abstract method with only definition, but other methods can be also in the abstract class with implementation…

I read a simple yet effective explanation of Abstract class and Interface on php.net

Which is as follows.

An Interface is like a protocol. It doesn’t designate the behavior of the object; it designates how your code tells that object to act. An interface would be like the English Language: defining an interface defines how your code communicates with any object implementing that interface.

An interface is always an agreement or a promise. When a class says “I implement interface Y”, it is saying “I promise to have the same public methods that any object with interface Y has”.

On the other hand, an Abstract Class is like a partially built class. It is much like a document with blanks to fill in. It might be using English, but that isn’t as important as the fact that some of the document is already written.

An abstract class is the foundation for another object. When a class says “I extend abstract class Y”, it is saying “I use some methods or properties already defined in this other class named Y”.

So, consider the following PHP:

  

You would have your class implement a particular interface if you were distributing a class to be used by other people. The interface is an agreement to have a specific set of public methods for your class.

You would have your class extend an abstract class if you (or someone else) wrote a class that already had some methods written that you want to use in your new class.

These concepts, while easy to confuse, are specifically different and distinct. For all intents and purposes, if you’re the only user of any of your classes, you don’t need to implement interfaces.