Interfaz vs clase abstracta (OO general)

Recientemente tuve dos entrevistas telefónicas en las que me preguntaron acerca de las diferencias entre una interfaz y una clase abstracta. Les expliqué todos los aspectos de los que pude pensar, pero parece que están esperando que mencione algo específico, y no sé qué es.

Desde mi experiencia, creo que lo siguiente es verdad. Si me falta un punto importante, házmelo saber.

Interfaz:

Todos y cada uno de los métodos declarados en una interfaz deberán implementarse en la subclase. Solo eventos, delegates, propiedades (C #) y métodos pueden existir en una interfaz. Una clase puede implementar múltiples interfaces.

Clase abstracta:

Solo los métodos abstractos tienen que ser implementados por la subclase. Una clase abstracta puede tener métodos normales con implementaciones. La clase abstracta también puede tener variables de clase junto a Eventos, Delegados, Propiedades y Métodos. Una clase solo puede implementar una clase abstracta solo debido a la inexistencia de Multi-herencia en C #.

  1. Después de todo eso, al entrevistador se le ocurrió la pregunta “¿Y si tuviera una clase de Resumen con solo métodos abstractos? ¿Cómo sería eso diferente de una interfaz?” No sabía la respuesta, pero creo que es la herencia como se mencionó anteriormente ¿no?

  2. Otro entrevistador me preguntó qué pasaría si tuviera una variable pública dentro de la interfaz, ¿cómo sería eso diferente de la clase abstracta? Insistí que no puedes tener una variable pública dentro de una interfaz. No sabía lo que quería oír, pero tampoco estaba satisfecho.

Ver también :

  • Cuándo usar una interfaz en lugar de una clase abstracta y viceversa

  • Interfaces vs. clases abstractas

  • ¿Cómo se decide entre usar una clase abstracta y una interfaz?

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

Si bien su pregunta indica que es para “OO general”, realmente parece centrarse en el uso de .NET de estos términos.

En .NET (similar para Java):

  • las interfaces no pueden tener estado o implementación
  • una clase que implementa una interfaz debe proporcionar una implementación de todos los métodos de esa interfaz
  • las clases abstractas pueden contener estados (miembros de datos) y / o implementación (métodos)
  • las clases abstractas se pueden heredar sin implementar los métodos abstractos (aunque dicha clase derivada es abstracta en sí misma)
  • las interfaces pueden ser hereditarias múltiples, las clases abstractas pueden no (esta es probablemente la razón más importante para que las interfaces existan por separado de las clases abstractas; permiten una implementación de herencia múltiple que elimina muchos de los problemas de MI general).

Como términos generales de OO, las diferencias no están necesariamente bien definidas. Por ejemplo, hay progtwigdores de C ++ que pueden tener definiciones rígidas similares (las interfaces son un subconjunto estricto de clases abstractas que no pueden contener la implementación), mientras que algunos pueden decir que una clase abstracta con algunas implementaciones predeterminadas sigue siendo una interfaz o no abstracta. la clase todavía puede definir una interfaz.

De hecho, existe un modismo de C ++ llamado Interfaz no virtual (NVI) en el que los métodos públicos son métodos no virtuales que ‘suenan’ a los métodos virtuales privados:

Qué tal una analogía: cuando estaba en la Fuerza Aérea, fui a entrenamiento de pilotos y me convertí en piloto de la USAF (Fuerza Aérea de los EE. UU.). En ese momento no estaba calificado para volar nada, y tuve que asistir al entrenamiento de tipo de aeronave. Una vez que califiqué, era piloto (clase de resumen) y piloto de C-141 (clase concreta). En una de mis tareas, se me asignó un deber adicional: Oficial de Seguridad. Ahora todavía era piloto y piloto de C-141, pero también desempeñaba funciones de Oficial de Seguridad (implementé ISafetyOfficer, por así decirlo). No se requirió que un piloto fuera un oficial de seguridad, otras personas podrían haberlo hecho también.

Todos los pilotos de la USAF tienen que seguir ciertas regulaciones de la Fuerza Aérea, y todos los pilotos C-141 (o F-16, o T-38) ‘son’ pilotos de la USAF. Cualquiera puede ser un oficial de seguridad. Entonces, para resumir:

  • Piloto: clase abstracta
  • C-141 Piloto: clase concreta
  • Oficial de ISafety: interfaz

Nota agregada: se suponía que era una analogía para ayudar a explicar el concepto, no una recomendación de encoding. Vea los diversos comentarios a continuación, la discusión es interesante.

Creo que la respuesta que están buscando es la diferencia filosófica fundamental o OPPS.

La herencia de la clase abstracta se usa cuando la clase derivada comparte las propiedades principales y el comportamiento de la clase abstracta. El tipo de comportamiento que realmente define la clase.

Por otro lado, la herencia de interfaz se usa cuando las clases comparten un comportamiento periférico, que no define necesariamente la clase derivada.

Por ej. Un automóvil y un camión comparten muchas propiedades centrales y el comportamiento de una clase abstracta de Automóvil, pero también comparten algún comportamiento periférico como Generar escape que incluso las clases no automotrices como Drillers o PowerGenerators comparten y no necesariamente define un automóvil o un camión. , por lo que Car, Truck, Driller y PowerGenerator pueden compartir la misma interfaz IExhaust.

Corto: las clases abstractas se usan para Modelar una jerarquía de clase de clases similares (por ejemplo, Animal puede ser una clase abstracta y Human, Lion, Tiger pueden ser clases derivadas concretas)

Y

La interfaz se utiliza para la comunicación entre 2 clases similares / no similares a las que no les importa el tipo de interfaz que implementa la clase (por ejemplo, Altura puede ser propiedad de la interfaz y puede ser implementada por Humano, Edificio, Árbol. No importa si puedes comer , puedes nadar, puedes morir o lo que sea … solo importa una cosa que necesites para tener Altura (implementación en tu clase)).

Hay un par de otras diferencias:

Las interfaces no pueden tener implementaciones concretas. Las clases base abstractas pueden. Esto le permite proporcionar implementaciones concretas allí. Esto puede permitir que una clase base abstracta proporcione realmente un contrato más riguroso, mientras que una interfaz realmente solo describe cómo se usa una clase. (La clase base abstracta puede tener miembros no virtuales que definen el comportamiento, lo que otorga más control al autor de la clase base).

Se puede implementar más de una interfaz en una clase. Una clase solo puede derivar de una sola clase base abstracta. Esto permite una jerarquía polimórfica usando interfaces, pero no clases base abstractas. Esto también permite una pseudo-multi-herencia usando interfaces.

Las clases base abstractas se pueden modificar en v2 + sin romper la API. Los cambios a las interfaces están rompiendo cambios.

[C # / .NET Specific] Las interfaces, a diferencia de las clases base abstractas, se pueden aplicar a tipos de valores (estructuras). Las estructuras no pueden heredar de clases base abstractas. Esto permite que los contratos de comportamiento / pautas de uso se apliquen a los tipos de valores.

Herencia
Considera un auto y un autobús. Son dos vehículos diferentes. Pero aún así, comparten algunas propiedades comunes como dirección, frenos, engranajes, motor, etc.
Entonces, con el concepto de herencia, esto puede representarse como sigue …

 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 arriba.

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 diferentes vehículos se conducen 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 controlador 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 cada hijo heredado debe implementar esta función.
Entonces, si modificas 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 comstackrá y se generará un error.
En resumen … una clase abstracta es una clase parcialmente incompleta con algunas funciones incompletas, que los niños que heredan deben especificar la suya propia.

Interfaces Las interfaces son totalmente incompletas. Ellos no tienen ninguna propiedad. Simplemente indican que los niños 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 .: llama a una persona. El creador del teléfono especifica cómo hacerlo. Aquí los teléfonos móviles pueden marcar un número, es decir, se puede marcar. Vamos a representar 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); } ..... 

Al utilizar interfaces en lugar de clases abstractas, el escritor de la función que utiliza un Dialable no necesita preocuparse por sus propiedades. Ejemplo: ¿Tiene una pantalla táctil o teclado de marcado? ¿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 más importante aún , si algún día cambia 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 todavía funciona perfectamente porque la función que utiliza el marcador no depende (y no puede) de los detalles que no sean los especificados en la interfaz de Dialable. Ambos implementan una interfaz Dialable y eso es lo único que le importa a la función.

Los desarrolladores suelen utilizar interfaces para garantizar la interoperabilidad (uso intercambiable) entre objetos, siempre que compartan una función común (al igual que puede cambiar a una línea fija o teléfono móvil, en la medida en que solo necesite marcar un número). En resumen, las interfaces son una versión mucho más simple de las clases abstractas, sin ninguna propiedad.
Además, tenga en cuenta que puede implementar (heredar) tantas interfaces como desee, pero solo puede extender (heredar) una única clase principal.

Más información Clases abstractas vs Interfaces

Si considera que java es un lenguaje OOP para responder a esta pregunta, la versión Java 8 hace que parte del contenido de las respuestas anteriores quede obsoleto. Ahora la interfaz de Java puede tener métodos predeterminados con implementación concreta.

El sitio web de Oracle proporciona diferencias clave entre la interface y abstract clase abstract .

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.

En términos simples, me gustaría usar

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

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

Eche un vistazo al ejemplo del código para comprender las cosas de manera clara: ¿cómo debería haber explicado la diferencia entre una interfaz y una clase abstracta?

Los entrevistadores están ladrando un árbol extraño. Para lenguajes como C # y Java, existe una diferencia, pero en otros lenguajes como C ++ no existe. La teoría de OO no diferencia los dos, simplemente la syntax del lenguaje.

Una clase abstracta es una clase con implementación e interfaz (métodos virtuales puros) que se heredará. Las interfaces generalmente no tienen ninguna implementación sino solo funciones virtuales puras.

En C # o Java, una clase abstracta sin implementación difiere de una interfaz solo en la syntax utilizada para heredar de ella y el hecho de que solo se puede heredar de una.

Al implementar las interfaces, usted está logrando la composición (relaciones “has-a”) en lugar de herencia (relaciones “is-a”). Ese es un principio importante para recordar cuando se trata de cosas como patrones de diseño en los que necesitas usar interfaces para lograr una composición de comportamientos en lugar de una herencia.

Explicaré Detalles de profundidad de la interfaz y la clase Resumen. Si conoce información general sobre la interfaz y la clase abstracta, entonces la primera pregunta llegará en su mente cuando deberíamos usar la Interfaz y cuando deberíamos usar la clase Resumen. Por lo tanto, verifique la explicación a continuación de Interfaz y clase abstracta.

  1. ¿Cuándo deberíamos usar Interface?

    Si no sabe acerca de la implementación solo tenemos especificación de requisitos, entonces vamos con Interface

  2. ¿Cuándo deberíamos usar Abstract Class?

    si conoce la implementación pero no completamente (parcialmente la implementación), entonces vamos con la clase Abstract.

    Interfaz

    cada método por defecto público abstracto significa que la interfaz es 100% pura abstracta.

    Abstracto

    puede tener el método concreto y el método abstracto, qué es el método concreto, que tienen implementación en la clase de resumen. Una clase abstracta es una clase que se declara abstracta; puede o no incluir métodos abstractos.

    Interfaz

    No podemos declarar la interfaz como privada, protegida

    P. ¿Por qué no declaramos la interfaz como privada y protegida?

    Debido a que el método de la interfaz por defecto es el resumen público, tenemos que razonar que no estamos declarando la interfaz como privada y protegida.

    Método de interfaz
    tampoco podemos declarar la interfaz como privada, protegida, final, estática, sincronizada, nativa …..

    Voy a dar la razón: por qué no estamos declarando el método sincronizado porque no podemos crear el objeto de la interfaz y sincronizamos el trabajo en el objeto así que nuestra razón es que no estamos declarando el método sincronizado El concepto transitorio tampoco es aplicable porque el trabajo transitorio con sincronizado.

    Abstracto

    estamos felices de usarlo con estática final pública, privada …. significa que no se aplican restricciones en abstracto.

    Interfaz

    Las variables se declaran en la interfaz como una final estática pública predeterminada, por lo que tampoco se declara la variable como privada, protegida.

    El modificador volátil tampoco es aplicable en la interfaz porque la variable de la interfaz es por defecto la variable final y final estática pública no puede cambiar el valor una vez que asigna el valor a la variable y una vez que declara la variable en la interfaz debe asignar la variable.

    Y la variable volátil es mantener los cambios por lo que es opp. al final esa es la razón por la que no usamos variables volátiles en la interfaz.

    Abstracto

    Variable abstracta no es necesario declarar pública estática final.

Espero que este artículo sea útil.

Para .Net,

Su respuesta a El segundo entrevistador también es la respuesta al primero … Las clases abstractas pueden tener implementación, Y el estado, las interfaces no pueden …

EDITAR: En otra nota, ni siquiera usaría la frase ‘subclase’ (o la frase ‘herencia’) para describir las clases que están ‘definidas para implementar’ una interfaz. Para mí, una interfaz es una definición de un contrato que una clase debe cumplir si se ha definido para ‘implementar’ esa interfaz. No hereda nada … Tienes que agregar todo tú mismo, explícitamente.

Conceptualmente hablando, mantener la implementación específica del idioma, las reglas, los beneficios y lograr cualquier objective de progtwigción al usar cualquiera o ambos, puede o no tener código / datos / propiedad, blah blah, herencias únicas o múltiples, todo a un lado

1- La clase abstracta (o abstracta pura) está destinada a implementar jerarquía. Si sus objetos comerciales se ven estructuralmente similares, representando un tipo de relación padre-hijo (jerarquía) solo entonces se usarán las clases de herencia / Resumen. Si su modelo de negocio no tiene una jerarquía, entonces la herencia no debe utilizarse (aquí no estoy hablando de lógica de progtwigción, por ejemplo, algunos patrones de diseño requieren herencia). Conceptualmente, la clase abstracta es un método para implementar la jerarquía de un modelo de negocio en OOP, no tiene nada que ver con Interfaces, en realidad comparar la clase abstracta con la interfaz no tiene sentido porque ambas son conceptualmente cosas totalmente diferentes, se pregunta en entrevistas solo para verificar el conceptos porque parece que ambos proporcionan la misma funcionalidad cuando se trata de la implementación y los progtwigdores usualmente enfatizamos más en la encoding. [Tenga esto en cuenta que la abstracción es diferente de la clase abstracta].

2- una interfaz es un contrato, una funcionalidad comercial completa representada por uno o más conjuntos de funciones. Es por eso que se implementa y no se hereda. Un objeto comercial (parte de una jerarquía o no) puede tener cualquier número de funcionalidad comercial completa. No tiene nada que ver con las clases abstractas significa herencia en general. Por ejemplo, un humano puede EJECUTAR, un elefante puede EJECUTAR, un pájaro puede EJECUTAR, y así sucesivamente, todos estos objetos de jerarquía diferente implementarían la interfaz RUN o la interfaz COMER o HABLAR. No entre en implementación, ya que podría implementarlo como teniendo clases abstractas para cada tipo que implemente estas interfaces. Un objeto de cualquier jerarquía puede tener una funcionalidad (interfaz) que no tiene nada que ver con su jerarquía.

Creo que las interfaces no se inventaron para lograr herencias múltiples o exponer el comportamiento público, y de manera similar, las clases abstractas puras no deben invalidar las interfaces, pero la interfaz es una funcionalidad que un objeto puede hacer (a través de funciones de esa interfaz) y la clase abstracta representa un padre de una jerarquía para producir hijos con estructura central (propiedad + funcionalidad) del padre

Cuando se le pregunta acerca de la diferencia, en realidad es la diferencia conceptual, no la diferencia en la implementación específica del idioma, a menos que se solicite explícitamente.

Creo que ambos entrevistadores esperaban una línea de diferencia directa entre estos dos y cuando fallaste intentaron llevarte hacia esta diferencia implementando UNO como el OTRO

¿Qué pasa si tienes una clase de Resumen con solo métodos abstractos?

Creo que no les gustó su respuesta porque dieron las diferencias técnicas en lugar de las de diseño. La pregunta es como una pregunta trol para mí. De hecho, las interfaces y las clases abstractas tienen una naturaleza completamente diferente, por lo que no puedes compararlas realmente. Le daré mi visión de cuál es el papel de una interfaz y cuál es el papel de una clase abstracta.

interfaz: se usa para asegurar un contrato y hacer un bajo acoplamiento entre clases para tener una aplicación más fácil de mantener, escalable y comprobable.

clase abstracta: solo se usa para factorizar un código entre clases de la misma responsabilidad. Tenga en cuenta que esta es la razón principal por la cual la herencia múltiple es algo malo en OOP, porque una clase no debería manejar muchas responsabilidades (use composición en su lugar).

Entonces, las interfaces tienen un rol arquitectónico real, mientras que las clases abstractas son casi solo un detalle de la implementación (si se usa correctamente, por supuesto).

 After all that, the interviewer came up with the question "What if you had an Abstract class with only abstract methods? How would that be different from an interface?" 

Los documentos dicen claramente que si una clase abstracta contiene solo declaraciones de métodos abstractos, debe declararse como una interfaz.

 An another interviewer asked me what if you had a Public variable inside the interface, how would that be different than in Abstract Class? 

Variables in Interfaces are by default public static and final. Question could be framed like what if all variables in abstract class are public? Well they can still be non static and non final unlike the variables in interfaces.

Finally I would add one more point to those mentioned above – abstract classes are still classes and fall in a single inheritance tree whereas interfaces can be present in multiple inheritance.

Copied from CLR via C# by Jeffrey Richter…

I often hear the question, “Should I design a base type or an interface?” The answer isn’t always clearcut.

Here are some guidelines that might help you:

■■ IS-A vs. CAN-DO relationship A type can inherit only one implementation. If the derived type can’t claim an IS-A relationship with the base type, don’t use a base type; use an interface. Interfaces imply a CAN-DO relationship. If the CAN-DO functionality appears to belong with various object types, use an interface. For example, a type can convert instances of itself to another type (IConvertible), a type can serialize an instance of itself (ISerializable), etc. Note that value types must be derived from System.ValueType, and therefore, they cannot be derived from an arbitrary base class. In this case, you must use a CAN-DO relationship and define an interface.

■■ Ease of use It’s generally easier for you as a developer to define a new type derived from a base type than to implement all of the methods of an interface. The base type can provide a lot of functionality, so the derived type probably needs only relatively small modifications to its behavior. If you supply an interface, the new type must implement all of the members.

■■ Consistent implementation No matter how well an interface contract is documented, it’s very unlikely that everyone will implement the contract 100 percent correctly. In fact, COM suffers from this very problem, which is why some COM objects work correctly only with Microsoft Word or with Windows Internet Explorer. By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.

■■ Versioning If you add a method to the base type, the derived type inherits the new method, you start off using a type that works, and the user’s source code doesn’t even have to be recompiled. Adding a new member to an interface forces the inheritor of the interface to change its source code and recompile.

Difference between Java Interface and Abstract Class

  1. Main difference is methods of a Java interface are implicitly abstract and cannot have implementations. A Java abstract class can have instance methods that implements a default behavior.

  2. Variables declared in a Java interface is by default final. An abstract class may contain non-final variables.

  3. Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private, protected, etc..

  4. Java interface should be implemented using keyword “implements”; A Java abstract class should be extended using keyword “extends”.

  5. An interface can extend another Java interface only, an abstract class can extend another Java class and implement multiple Java interfaces.

  6. A Java class can implement multiple interfaces but it can extend only one abstract class.

  7. Interface is absolutely abstract and cannot be instantiated; A Java abstract class also cannot be instantiated, but can be invoked if a main() exists.

  8. In comparison with java abstract classes, java interfaces are slow as it requires extra indirection.

  1. Interfaz:
    • We do not implement (or define) methods, we do that in derived classes.
    • We do not declare member variables in interfaces.
    • Interfaces express the HAS-A relationship. That means they are a mask of objects.
  2. Abstract class:
    • We can declare and define methods in abstract class.
    • We hide constructors of it. That means there is no object created from it directly.
    • Abstract class can hold member variables.
    • Derived classes inherit to abstract class that mean objects from derived classes are not masked, it inherit to abstract class. The relationship in this case is IS-A.

This is my opinion.

Interface : should be used if you want to imply a rule on the components which may or may not be related to each other

Pros:

  1. Allows multiple inheritance
  2. Provides abstraction by not exposing what exact kind of object is being used in the context
  3. provides consistency by a specific signature of the contract

Contras:

  1. Must implement all the contracts defined
  2. Cannot have variables or delegates
  3. Once defined cannot be changed without breaking all the classes

Abstract Class : should be used where you want to have some basic or default behaviour or implementation for components related to each other

Pros:

  1. Faster than interface
  2. Has flexibility in the implementation (you can implement it fully or partially)
  3. Can be easily changed without breaking the derived classes

Contras:

  1. Cannot be instantiated
  2. Does not support multiple inheritance

Most answers focus on the technical difference between Abstract Class and Interface, but since technically, an interface is basically a kind of abstract class (one without any data or implementation), I think the conceptual difference is far more interesting, and that might be what the interviewers are after.

An Interface is an agreement . It specifies: “this is how we’re going to talk to each other”. It can’t have any implementation because it’s not supposed to have any implementation. It’s a contract. It’s like the .h header files in C.

An Abstract Class is an incomplete implementation . A class may or may not implement an interface, and an abstract class doesn’t have to implement it completely. An abstract class without any implementation is kind of useless, but totally legal.

Basically any class, abstract or not, is about what it is , whereas an interface is about how you use it . For example: Animal might be an abstract class implementing some basic metabolic functions, and specifying abstract methods for breathing and locomotion without giving an implementation, because it has no idea whether it should breathe through gills or lungs, and whether it flies, swims, walks or crawls. Mount , on the other hand, might be an Interface, which specifies that you can ride the animal, without knowing what kind of animal it is (or whether it’s an animal at all!).

The fact that behind the scenes, an interface is basically an abstract class with only abstract methods, doesn’t matter. Conceptually, they fill totally different roles.

An interface defines a contract for a service or set of services. They provide polymorphism in a horizontal manner in that two completely unrelated classes can implement the same interface but be used interchangeably as a parameter of the type of interface they implement, as both classes have promised to satisfy the set of services defined by the interface. Interfaces provide no implementation details.

An abstract class defines a base structure for its sublcasses, and optionally partial implementation. Abstract classes provide polymorphism in a vertical, but directional manner, in that any class that inherits the abstract class can be treated as an instance of that abstract class but not the other way around. Abstract classes can and often do contain implementation details, but cannot be instantiated on their own- only their subclasses can be “newed up”.

C# does allow for interface inheritance as well, mind you.

Abstract class And Interface Difference :

  1. Abstract class can have abstract and non-abstract methods and Interface can have only abstract methods.
  2. Abstract class doesn’t support multiple inheritance And Interface supports multiple inheritance.
  3. Abstract class can have final, non-final, static and non-static variables And Interface has only static and final variables.
  4. Abstract class can have static methods, main method and constructor And Interface can’t have static methods, main method or constructor.
  5. Abstract class can provide the implementation of interface And Interface can’t provide the implementation of abstract class.
  6. The abstract keyword is used to declare abstract class And The interface keyword is used to declare interface.
  7. Abstract class achieves partial abstraction (0 to 100%) because there are non abstract methods also in abstract class whereas interface achieves fully abstraction (100%).

As you might have got the theoretical knowledge from the experts, I am not spending much words in repeating all those here, rather let me explain with a simple example where we can use/cannot use Interface and Abstract class .

Consider you are designing an application to list all the features of Cars. In various points you need inheritance in common, as some of the properties like DigitalFuelMeter, Air Conditioning, Seat adjustment, etc are common for all the cars. Likewise, we need inheritance for some classes only as some of the properties like the Braking system (ABS,EBD) are applicable only for some cars.

The below class acts as a base class for all the cars:

 public class Cars { public string DigitalFuelMeter() { return "I have DigitalFuelMeter"; } public string AirCondition() { return "I have AC"; } public string SeatAdjust() { return "I can Adjust seat"; } } 

Consider we have a separate class for each Cars.

 public class Alto : Cars { // Have all the features of Car class } public class Verna : Cars { // Have all the features of Car class + Car need to inherit ABS as the Braking technology feature which is not in Cars } public class Cruze : Cars { // Have all the features of Car class + Car need to inherit EBD as the Braking technology feature which is not in Cars } 

Consider we need a method for inheriting the Braking technology for the cars Verna and Cruze (not applicable for Alto). Though both uses braking technology, the “technology” is different. So we are creating an abstract class in which the method will be declared as Abstract and it should be implemented in its child classes.

 public abstract class Brake { public abstract string GetBrakeTechnology(); } 

Now we are trying to inherit from this abstract class and the type of braking system is implemented in Verna and Cruze:

 public class Verna : Cars,Brake { public override string GetBrakeTechnology() { return "I use ABS system for braking"; } } public class Cruze : Cars,Brake { public override string GetBrakeTechnology() { return "I use EBD system for braking"; } } 

See the problem in the above two classes? They inherit from multiple classes which C#.Net doesn’t allow even though the method is implemented in the children. Here it comes the need of Interface.

 interface IBrakeTechnology { string GetBrakeTechnology(); } 

And the implementation is given below:

 public class Verna : Cars, IBrakeTechnology { public string GetBrakeTechnology() { return "I use ABS system for braking"; } } public class Cruze : Cars, IBrakeTechnology { public string GetBrakeTechnology() { return "I use EBD system for braking"; } } 

Now Verna and Cruze can achieve multiple inheritance with its own kind of braking technologies with the help of Interface.

Interfaces are light weight way to enforce a particular behavior. That is one way to think of.

1) An interface can be seen as a pure Abstract Class, is the same, but despite this, is not the same to implement an interface and inheriting from an abstract class. When you inherit from this pure abstract class you are defining a hierarchy -> inheritance, if you implement the interface you are not, and you can implement as many interfaces as you want, but you can only inherit from one class.

2) You can define a property in an interface, so the class that implements that interface must have that property.

Por ejemplo:

  public interface IVariable { string name {get; set;} } 

The class that implements that interface must have a property like that.

From another answer of mine , mostly dealing with when to use one versus the other:

In my experience, interfaces are best used when you have several classes which each need to respond to the same method or methods so that they can be used interchangeably by other code which will be written against those classes’ common interface. The best use of an interface is when the protocol is important but the underlying logic may be different for each class. If you would otherwise be duplicating logic, consider abstract classes or standard class inheritance instead.

Though this question is quite old, I would like to add one other point in favor of interfaces:

Interfaces can be injected using any Dependency Injection tools where as Abstract class injection supported by very few.

Answer to the second question : public variable defined in interface is static final by default while the public variable in abstract class is an instance variable.

Interface Types vs. Abstract Base Classes

Adapted from the Pro C# 5.0 and the .NET 4.5 Framework book.

The interface type might seem very similar to an abstract base class. Recall that when a class is marked as abstract, it may define any number of abstract members to provide a polymorphic interface to all derived types. However, even when a class does define a set of abstract members, it is also free to define any number of constructors, field data, nonabstract members (with implementation), and so on. Interfaces, on the other hand, contain only abstract member definitions. The polymorphic interface established by an abstract parent class suffers from one major limitation in that only derived types support the members defined by the abstract parent. However, in larger software systems, it is very common to develop multiple class hierarchies that have no common parent beyond System.Object. Given that abstract members in an abstract base class apply only to derived types, we have no way to configure types in different hierarchies to support the same polymorphic interface. By way of example, assume you have defined the following abstract class:

 public abstract class CloneableType { // Only derived types can support this // "polymorphic interface." Classes in other // hierarchies have no access to this abstract // member. public abstract object Clone(); } 

Given this definition, only members that extend CloneableType are able to support the Clone() method. If you create a new set of classes that do not extend this base class, you can’t gain this polymorphic interface. Also, you might recall that C# does not support multiple inheritance for classes. Therefore, if you wanted to create a MiniVan that is-a Car and is-a CloneableType, you are unable to do so:

 // Nope! Multiple inheritance is not possible in C# // for classes. public class MiniVan : Car, CloneableType { } 

As you would guess, interface types come to the rescue. After an interface has been defined, it can be implemented by any class or structure, in any hierarchy, within any namespace or any assembly (written in any .NET programming language). As you can see, interfaces are highly polymorphic. Consider the standard .NET interface named ICloneable, defined in the System namespace. This interface defines a single method named Clone():

 public interface ICloneable { object Clone(); } 

For sure it is important to understand the behavior of interface and abstract class in OOP (and how languages handle them), but I think it is also important to understand what exactly each term means. Can you imagine the if command not working exactly as the meaning of the term? Also, actually some languages are reducing, even more, the differences between an interface and an abstract… if by chance one day the two terms operate almost identically, at least you can define yourself where (and why) should any of them be used for.

If you read through some dictionaries and other fonts you may find different meanings for the same term but having some common definitions. I think these two meanings I found in this site are really, really good and suitable.

Interfaz:

A thing or circumstance that enables separate and sometimes incompatible elements to coordinate effectively.

Abstracto:

Something that concentrates in itself the essential qualities of anything more extensive or more general, or of several things; essence.

Ejemplo:

You bought a car and it needs fuel.

enter image description here

Your car model is XYZ , which is of genre ABC , so it is a concrete car, a specific instance of a car. A car is not a real object. In fact, it is an abstract set of standards (qualities) to create a specific object. In short, Car is an abstract class , it is “something that concentrates in itself the essential qualities of anything more extensive or more general” .

The only fuel that matches the car manual specification should be used to fill up the car tank. In reality, there is nothing to restrict you to put any fuel but the engine will work properly only with the specified fuel, so it is better to follow its requirements. The requirements say that it accepts, as other cars of the same genre ABC , a standard set of fuel.

In an Object Oriented view, fuel for genre ABC should not be declared as a class because there is no concrete fuel for a specific genre of car out there. Although your car could accept an abstract class Fuel or VehicularFuel, you must remember that your only some of the existing vehicular fuel meet the specification, those that implement the requirements in your car manual. In short, they should implement the interface ABCGenreFuel , which “… enables separate and sometimes incompatible elements to coordinate effectively” .

Apéndice

In addition, I think you should keep in mind the meaning of the term class, which is (from the same site previously mentioned):

Clase:

A number of persons or things regarded as forming a group by reason of common attributes, characteristics, qualities, or traits; kind;

This way, a class (or abstract class) should not represent only common attributes (like an interface), but some kind of group with common attributes. An interface doesn’t need to represent a kind. It must represent common attributes. This way, I think classes and abstract classes may be used to represent things that should not change its aspects often, like a human being a Mammal, because it represents some kinds. Kinds should not change themselves that often.

Couple of other differences:

Abstract classes can have static methods, properties, fields etc. and operators, interfaces can’t. Cast operator allows casting to/from abstract class but don’t allow casting to/from interface.

So pretty much you can use abstract class on its own even if it is never implemented (through its static members) and you can’t use interface on its own in any way.