Interfaz vs Clase Abstracta (general OO)

Qué tal una analogía: cuando estaba en la Fuerza Aérea, fui a entrenamiento de piloto y me convertí en piloto de la USAF (Fuerza Aérea de los Estados Unidos). En ese momento no estaba calificado para volar nada, y tuve que asistir a un entrenamiento de tipo de avión. Una vez calificado, fui piloto (clase Abstracta) y piloto C-141 (clase concreta). En una de mis asignaciones, me asignaron una tarea adicional: Oficial de Seguridad. Ahora todavía era piloto y piloto de C-141, pero también desempeñé funciones de Oficial de Seguridad (implementé ISafetyOfficer, así que para hablar). No se requería 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
• Piloto C-141: clase de hormigón
• iSafety Officer: interface

Nota añadida: esto estaba destinado a ser una analogía para ayudar a explicar el concepto, no un recomendación de codificación. Ver 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 u OPPS.

La herencia de 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 necesariamente definen la clase derivada.

Por ejemplo. Un coche y un camión comparten un muchas de las propiedades principales 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 Perforadores o generadores de energía 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 clases de aspecto similar (Por ejemplo, Animal puede ser clase abstracta y Humano, León, Tigre pueden ser clases derivadas concretas)

Y

Interfaz se utiliza para Comunicación entre 2 clases similares / no similares que no se preocupan por el tipo de la clase de implementación de Interfaz(por ejemplo , Altura puede ser propiedad de interfaz y se puede implementar por Humano , Edificio, Árbol. No importa si puedes comer, puedes nadar, puedes morir o cualquier cosa.. solo importa una cosa que necesita tener Altura (implementación en su 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 un contrato más riguroso, donde una interfaz realmente solo describe cómo se usa una clase. (La clase base abstracta puede tener miembros no virtuales definiendo el comportamiento, lo que le da más control al autor de la clase base.)

Más de una interfaz se puede implementar 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 en las interfaces son cambios radicales.

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

Herencia
Considere un coche y un autobús. Son dos vehículos diferentes. Pero aún así, comparten algunas propiedades comunes como tienen una dirección, frenos, engranajes, motor, etc.
Así que con el concepto de herencia, esto se puede representar como siguiente ...

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

public class Car extends Vehicle {
    private Engine engine;
    private Door[] doors;
}

Eso es todo sobre Herencia. Los usamos para clasificar objetos en formas base 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.
Se puede conducir un vehículo. ¿Verdad? Pero diferentes vehículos son conducidos de diferentes maneras ... Por ejemplo, no se puede conducir un coche igual que se 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; lo haría tener 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 hijos herederos deben implementar esta función.
Así que si usted modifica la clase de vehículo ...

//......Code of Vehicle Class
abstract public void drive();
//.....Code continues

La Bicicleta y el coche también deben especificar cómo conducirlo. De lo contrario, el código no se compilará y se producirá un error.
En resumen.. una clase abstracta es una clase parcialmente incompleta con algunas funciones incompletas, que los hijos herederos deben especificar las suyas propias.

Interfaces Las interfaces están totalmente incompletas. No tienen propiedades. 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 maneras de hacer diferentes funciones; Por ejemplo: llamar a una persona. El fabricante del teléfono especifica cómo hacerlo. Aquí los teléfonos móviles pueden marcar una número-es decir, es capaz de marcar. Representemos esto como una interfaz.

public interface Dialable {
    public void dial(Number n);
}

Aquí el creador del Dialable define cómo marcar un número. Solo tienes que 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);
}
.....

Usando interfaces en lugar de clases abstractas, el escritor de la función que usa un Dialable no necesita preocuparse por sus propiedades. Por ejemplo: ¿Tiene una pantalla táctil o un panel de marcación, es un teléfono fijo o un teléfono móvil. Solo necesita saber si se puede marcar; ¿lo hace heredar (o implementar) 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 todavía funciona perfectamente porque la función que utiliza el dialable no depende (y no puede depender) de los detalles que no sean los especificados en la interfaz Dialable. Ambos implementan una interfaz dialable y eso es lo único que le importa a la función.

Las interfaces se utilizan comúnmente por los desarrolladores para garantizar la interoperabilidad (uso indistintamente) entre objetos, en la medida en que comparten 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 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 clase padre único.

Más información Resumen clases vs Interfaces

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

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

Considere usar clases abstractas si:

1. desea compartir código entre varias clases estrechamente relacionadas.
2. Usted espera que las clases que se extienden su clase abstracta tiene muchos métodos o campos comunes, o requiere 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 la interfaz Serializable.
2. Desea especificar el comportamiento de un tipo de datos en particular, pero no preocupado por quién implementa su comportamiento.
3. Desea aprovechar la herencia múltiple de tipo.

En términos simples, me gustaría usar

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

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

Echa un vistazo al ejemplo de código para entender las cosas de una manera clara: han 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, hay una diferencia, pero en otros lenguajes, como C++ no existe. La teoría OO no diferencia los dos, simplemente la sintaxis 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 ninguna la implementación difiere de una interfaz solo en la sintaxis utilizada para heredar de ella y el hecho de que solo puede heredar de una.

Mediante la implementación de interfaces se está logrando la composición (relaciones"tiene-a") en lugar de la herencia (relaciones"es-a"). Ese es un principio importante a recordar cuando se trata de cosas como patrones de diseño donde se necesita usar interfaces para lograr una composición de comportamientos en lugar de una herencia.

Explicaré los Detalles de Profundidad de la interfaz y la clase Abstracta.si conoce la descripción general sobre la interfaz y la clase abstracta, entonces la primera pregunta llegará a su mente cuando deberíamos usar la Interfaz y cuando deberíamos usar la clase Abstracta. Así que por favor revise a continuación la explicación de la interfaz y la clase abstracta.

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

   si usted no sabe acerca de la implementación solo tenemos especificación de requisitos, entonces vamos con Interfaz

2. ¿Cuándo debemos usar Clase Abstracta?

   si conoces la implementación pero no completamente (implementación parcial) entonces vamos con Clase abstracta.

   Interfaz

   Cada método por defecto public abstract significa que la interfaz es 100% abstracta pura.

   Resumen

   Puede tener método concreto y método abstracto, lo que es método concreto, que tienen implementación en clase abstracta, 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 estamos declarando la Interfaz como privada y protegida?

   Porque por defecto el método de interfaz es public abstract so y so esa razón por la que no estamos declarando la interfaz como privada y protegida.

   Método de Interfaz
   también no podemos declarar interfaz como privado, protegido, final, estático, sincronizado, nativo.....

   Daré la razón: por qué no estamos declarando el método sincronizado porque no podemos crear el objeto de interfaz y sincronizar estamos trabajando en el objeto por lo que y razón hijo que no estamos declarando el método sincronizado Concepto transitorio tampoco son aplicables porque el trabajo transitorio con sincronizado.

   Resumen

   Estamos felices de usar con estática final pública,privada.... significa que no hay restricción aplicable en abstracto.

   Interfaz

   Las variables se declaran en la Interfaz como una final estática pública por defecto, por lo que tampoco estamos declaradas como una variable privada, protegida.

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

   Y la variable volátil es keep on changes por lo que es opp. al final que es la razón por la que no estamos usando variable volátil en la interfaz.

   Resumen

   Variable abstracta no hay necesidad de declarar final estático público.

Espero que este artículo sea útil.

Conceptualmente hablando, manteniendo la implementación específica del lenguaje, reglas, beneficios y logrando cualquier objetivo de programación mediante el uso de cualquiera o ambos, puede o no tener código/datos/propiedad, bla, bla, herencias simples o múltiples, todo a un lado

1 - La clase abstracta (o abstracta pura) está destinada a implementar la jerarquía. Si sus objetos de negocio se ven algo estructuralmente similares, representando un tipo de relación padre-hijo (jerarquía) solo entonces se usarán clases de herencia/Abstractas. Si su modelo de negocio no tiene una jerarquía, entonces no se debe usar la herencia (aquí no estoy hablando de lógica de programación, por ejemplo, algunos patrones de diseño requieren herencia). Conceptualmente, 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 clase abstracta con Interfaz no tiene sentido porque ambos son conceptualmente cosas totalmente diferentes, se pide en entrevistas solo para comprobar los conceptos porque parece que ambos proporcionan algo la misma funcionalidad cuando la implementación se refiere y los programadores por lo general hacen hincapié más en la codificación. [Tenga esto en cuenta también que la abstracción es diferente de la Clase Abstracta].

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

I cree que las interfaces no se inventaron para lograr múltiples herencias o para exponer el comportamiento público, y del mismo modo, las clases abstractas puras no son para invalidar las interfaces, sino que 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 que]}

Cuando se le pregunta acerca de la diferencia, en realidad es la diferencia conceptual no el 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 trataron de conducirte hacia esta diferencia implementando UNO como el OTRO

¿Qué pasaría si tuviera una clase abstracta con solo métodos abstractos?

Para. Net,

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

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 ha sido definida para 'implementar' esa interfaz. Lo hace no heredar nada... Tienes que añadir todo tú mismo, explícitamente.

Creo que no les gustó tu respuesta porque diste las diferencias técnicas en lugar de las de diseño. La pregunta es como una pregunta de troll para mí. De hecho, las interfaces y las clases abstractas tienen una naturaleza completamente diferente, por lo que realmente no se pueden comparar. Les 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 utiliza para asegurar un contrato y hacer un acoplamiento bajo entre clases con el fin de tener un aplicación más mantenible, escalable y comprobable.

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

Así que las interfaces tienen un papel arquitectónico real, mientras que las clases abstractas son casi solo un detalle de implementación (si lo 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 en su lugar.

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

Las variables en las interfaces son por defecto estáticas públicas y finales. Pregunta podría ser enmarcado como lo que si todas las variables en clase abstracta son públicas? Bueno, todavía pueden ser no estáticos y no finales a diferencia de las variables en interfaces.

Finalmente me gustaría añadir un punto más a los mencionados anteriormente-clases abstractas siguen siendo clases y caen en un solo árbol de herencia, mientras que las interfaces pueden estar presentes en herencia múltiple.

Diferencia entre la interfaz Java y la Clase Abstracta

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 implementen un comportamiento predeterminado.

2. Las variables declaradas en una interfaz Java son por defecto finales. 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 tenga los sabores habituales de los miembros de la clase como privado, protegido, etc..

4. La interfaz Java debe ser implementada usando la palabra clave "implements" ; Una clase abstracta Java debe ser extendida usando la palabra clave "extends".

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

6. Una clase Java puede implementar múltiples interfaces, pero solo puede extender un resumen clase.

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

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

1. Interfaz:
   • No implementamos (o definimos) métodos, lo hacemos en clases derivadas.
   • No declaramos variables miembro en interfaces.
   • Las interfaces expresan la relación HAS-A. Eso significa que son una máscara de objetos.
2. clase Abstracta:
   • Podemos declarar y definir métodos en clase abstracta.
   • Escondemos constructores de ella. Eso significa que no hay ningún objeto creado directamente a partir de él.
   • La clase abstracta puede contener miembro variable.
   • Las clases derivadas heredan a la clase abstracta que significa que los objetos de las clases derivadas no están enmascarados, heredan a la clase abstracta. La relación en este caso es IS-A.

Esta es mi opinión.

Copiado de CLR vía C# por Jeffrey Richter...

A menudo escucho la pregunta, " ¿Debo diseñar un tipo base o una interfaz?"La respuesta no siempre es clara.

Aquí hay algunas pautas que podrían ayudarlo:

■■ Relación IS-A vs.CAN-DO Un tipo puede heredar solo una implementación. Si el derivado type can't claim an IS-A relationship with the base type, don't use a base type; use an interface. Las interfaces implican una relación POSITIVA. Si la funcionalidad parece pertenecer con varios tipos de objetos, utilice una interfaz. Por ejemplo, un tipo puede convertir instancias de sí mismo a otro tipo (IConvertible), un tipo puede serializar una instancia de sí mismo (ISerializable), sucesivamente. Tenga en cuenta que los tipos de valor deben derivarse del Sistema.ValueType, y por lo tanto, no pueden derivar de una clase base arbitraria. En este caso, debe utilizar una relación de y definir una interfaz.

■■ Facilidad de uso Generalmente es más fácil para usted como desarrollador definir un nuevo tipo derivado de un tipo base que implementar todos los métodos de una interfaz. El tipo base puede proporcionar un gran cantidad de funcionalidad, por lo que el tipo derivado probablemente solo necesita modificaciones relativamente pequeñas a su comportamiento. Si proporciona una interfaz, el nuevo tipo debe implementar todos los miembros.

■■ Implementación consistente No importa lo bien que se documente un contrato de interfaz, es muy poco probable que todo el mundo va a implementar el contrato 100 por ciento correctamente. En realidad, COM sufre de este mismo problema, por lo que algunos objetos COM funcionan correctamente solo con Microsoft Word o con Windows Internet Explorer. Al proporcionar un tipo base con una buena implementación predeterminada, comienza usando un tipo que funciona y está bien probado; luego puede modifique las partes que necesitan modificación.

■■ Versionado Si agrega un método al tipo base, el tipo derivado hereda el nuevo método, empiezas usando un tipo que funciona, y el código fuente del usuario ni siquiera tiene para ser recompilada. Agregar un nuevo miembro a una interfaz obliga al heredero de la interfaz a cambiar su código fuente y recompilar.

Interfaz : debe utilizarse si desea implicar una regla sobre los componentes que pueden o no ser relacionados entre sí

Ventajas:

1. Permite la herencia múltiple
2. Proporciona abstracción al no exponer qué tipo exacto de objeto se está utilizando en el contexto
3. proporciona coherencia mediante una firma específica del contrato

Contras:

1. Debe implementar todos los contratos definido
2. No puede tener variables o delegados
3. Una vez definido no se puede cambiar sin romper todas las clases

Clase Abstracta : se debe usar cuando se desea tener algún comportamiento básico o predeterminado o implementación para componentes relacionados entre sí

Ventajas:

1. Más rápido que la interfaz
2. Tiene flexibilidad en la implementación (se puede implementar total o parcialmente)
3. Puede ser fácilmente cambiado sin romper las clases derivadas

Contras:

1. No se puede crear una instancia
2. No admite herencia múltiple

Una interfaz define un contrato para un servicio o conjunto de servicios. Proporcionan polimorfismo de una manera horizontal en que dos clases completamente no relacionadas pueden implementar la misma interfaz pero ser utilizadas indistintamente como un parámetro del tipo de interfaz que implementan, ya que ambas clases han prometido satisfacer el conjunto de servicios definidos por la interfaz. Las interfaces no proporcionan detalles de implementación.

Una clase abstracta define una estructura base para sus sublcases, y opcionalmente implementación parcial. Las clases abstractas proporcionan polimorfismo de manera vertical, pero direccional, en el sentido de que cualquier clase que hereda la clase abstracta puede ser tratada como una instancia de esa clase abstracta, pero no al revés. Las clases abstractas pueden y a menudo contienen detalles de implementación, pero no pueden ser instanciadas por sí mismas - solo sus subclases pueden ser "renovadas".

C# también permite la herencia de interfaces.

La mayoría de las respuestas se centran en la diferencia técnica entre la Clase Abstracta y la Interfaz, pero como técnicamente, una interfaz es básicamente una clase abstracta (una sin ningún dato o implementación), creo que la diferencia conceptual es mucho más interesante, y eso podría ser lo que buscan los entrevistadores.

Una interfaz es un acuerdo . Especifica: "así es como vamos a hablar entre nosotros". No puede tener ninguna implementación porque no se supone que tenga ninguna implementación. Es un contrato. Es como los archivos de cabecera .h en C.

Una Clase abstracta es una implementación incompleta. Una clase puede o no implementar una interfaz y una clase abstracta no tiene que implementar completamente. Una clase abstracta sin ninguna implementación es inútil, pero totalmente legal.

Básicamente cualquier clase, abstracta o no, se trata de lo que es , mientras que una interfaz se trata de cómo se usa. Por ejemplo: Animal podría ser una clase abstracta que implementa algunas funciones metabólicas básicas, y especifica métodos abstractos para la respiración y la locomoción sin dar una implementación, porque no tiene idea de si debe respirar a través de branquias o pulmones, y si vuela, nada, camina o se arrastra. Mount, por otro lado, podría ser una Interfaz, que especifica que se puede montar el animal, sin saber qué tipo de animal es (o si es un animal!).

El hecho de que detrás de las escenas, una interfaz es básicamente una clase abstracta con solo métodos abstractos, no importa. Conceptualmente, cumplen funciones totalmente diferentes.

Clase abstracta Y Diferencia De Interfaz:

1. La clase abstracta puede tener métodos abstractos y no abstractos y la Interfaz solo puede tener métodos abstractos.
2. La clase abstracta no admite herencia múltiple Y la interfaz admite herencia múltiple.
3. La clase abstracta puede tener variables finales, no finales, estáticas y no estáticas y la Interfaz solo tiene variables estáticas y finales.
4. La clase abstracta puede tener métodos estáticos, método principal y constructor E Interfaz no pueden tener métodos estáticos, método principal o constructor.
5. La clase abstracta puede proporcionar la implementación de la interfaz y la interfaz no puede proporcionar la implementación de la clase abstracta.
6. La palabra clave abstract se usa para declarar clase abstracta Y La palabra clave interface se usa para declarar interfaz.
7. La clase abstracta logra abstracción parcial (0 a 100%) porque hay métodos no abstractos también en la clase abstracta, mientras que interface logra completamente abstracción (100%).

Como es posible que haya obtenido el conocimiento teórico de los expertos, no estoy gastando muchas palabras en repetir todos estos aquí, más bien permítanme explicar con un simple ejemplo donde podemos usar/no podemos usar Interface y Abstract class.

Considere que está diseñando una aplicación para enumerar todas las características de los automóviles. En varios puntos necesita herencia en común, ya que algunas de las propiedades como DigitalFuelMeter, Aire Acondicionado, Ajuste de asiento, etc son comunes para todos los coches. Del mismo modo, necesitamos herencia para algunas clases solo como algunas de las propiedades como el sistema de frenado (ABS, EBD) son aplicables solo para algunos coches.

La siguiente clase actúa como una clase base para todos los coches:

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";
    }
}

Considere que tenemos una clase separada para cada coche.

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        
}

Considere que necesitamos un método para heredar la tecnología de frenado para los coches Verna y Cruze (no aplicable para Alto). Aunque ambos utilizan tecnología de frenado, la "tecnología" es diferente. Así que estamos creando un clase abstracta en la cual el método será declarado como Abstracto y debería ser implementado en sus clases secundarias.

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

Ahora estamos tratando de heredar de esta clase abstracta y el tipo de sistema de frenado se implementa en Verna y 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";
    }         
}

Ver el problema en las dos clases anteriores? Heredan de múltiples clases que C#.Net no permite a pesar de que el método se implementa en los niños. Aquí viene la necesidad de Interfaz.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

Y el 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";
   }        
}

Ahora Verna y Cruze pueden lograr una herencia múltiple con su propio tipo de tecnologías de frenado con la ayuda de Interface.

Las interfaces son una forma ligera de imponer un comportamiento particular. Esa es una forma de pensar.

1) Una interfaz puede ser vista como una Clase Abstracta pura, es lo mismo, pero a pesar de esto, no es lo mismo implementar una interfaz y heredar de una clase abstracta. Cuando hereda de esta clase abstracta pura, está definiendo una jerarquía - > herencia, si implementa la interfaz que no es, y puede implementar tantas interfaces como desee, pero solo puede heredar de una clase.

2) Puede definir una propiedad en una interfaz, por lo que la clase que implementa la interfaz debe tener esa propiedad.

Por ejemplo:

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

La clase que implementa esa interfaz debe tener una propiedad como esa.

Aunque esta pregunta es bastante antigua, me gustaría añadir otro punto a favor de las interfaces:

Las interfaces se pueden inyectar usando cualquier herramienta de Inyección de dependencias donde como inyección de clase abstracta soportada por muy pocos.

Respuesta a la segunda pregunta : public la variable definida en interface es static final por defecto mientras que la variable public en la clase abstract es una variable de instancia.

De otra respuesta mía , que trata principalmente de cuándo usar una contra la otra:

En mi experiencia, las interfaces son las mejores se usa cuando tienes varias clases que cada necesidad de responder a la misma método o métodos para que puedan ser utilizado indistintamente por otro código que se escribirá contra los interfaz común de las clases. El mejor el uso de una interfaz es cuando el protocolo es importante, pero el la lógica subyacente puede ser diferente para cada clase. Si usted fuera de otra manera duplicar lógica, considerar abstracto clases o herencia de clase estándar en su lugar.

Tipos de Interfaz vs Clases Base Abstractas

Adaptado del Pro C# 5.0 y del libro.NET 4.5 Framework.

El tipo de interfaz puede parecer muy similar a una clase base abstracta. Recordar que cuando una clase es marcada como abstracta, puede definir cualquier número de miembros abstractos para proporcionar una interfaz polimórfica a todos los tipos derivados. Sin embargo, incluso cuando una clase define un conjunto de abstractos miembros, también es libre de definir cualquier número de constructores, campo datos, miembros nonabstract (con implementación), y así sucesivamente. Las interfaces, por otro lado, contienen solo definiciones abstractas de miembros. La interfaz polimórfica establecida por una clase padre abstracta sufre de una limitación importante en eso solo los tipos derivados soportan los miembros definidos por el padre abstracto. Sin embargo, en mayor medida sistemas de software, es muy común desarrollar múltiples jerarquías de clase que no tienen un padre común más allá del Sistema.Objeto. Dado que los miembros abstractos en un resumen la clase base se aplica solo a los derivados tipos, no tenemos forma de configurar tipos en diferentes jerarquías para soportar el mismo polimórfico interfaz. A modo de ejemplo, supongamos que ha definido la siguiente clase abstracta:

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();
}

Dada esta definición, solo los miembros que extienden CloneableType son capaces de soportar el Clon() método. Si crea un nuevo conjunto de clases que no amplían esta clase base, no puede obtener esto interfaz polimórfica. Además, es posible que recuerde que C# no admite herencia múltiple para clases. Por lo tanto, si desea crear una MiniVan que es-un automóvil y es-un tipo CloneableType, no puede hacerlo:

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

Como adivinarías, los tipos de interfaz vienen al rescate. Después de que una interfaz ha sido definida, puede ser implementado por cualquier clase o estructura, en cualquier jerarquía, dentro de cualquier espacio de nombres o cualquier ensamblado (escrito en cualquier lenguaje de programación. NET). Como puede ver, las interfaces son altamente polimórficas. Considere la interfaz estándar. NET llamada ICloneable, definido en el espacio de nombres del sistema. Este la interfaz define un único método llamado Clone ():

public interface ICloneable
{
object Clone();
}

Desde la Perspectiva de la Codificación

Una Interfaz puede reemplazar una Clase Abstracta si la Clase Abstracta solo tiene métodos abstractos. De lo contrario, cambiar la clase abstracta a la interfaz significa que perderá la reutilización del código que proporciona la herencia.

Desde la Perspectiva del Diseño

Manténgalo como una Clase Abstracta si es una relación "Es una" y necesita un subconjunto o toda la funcionalidad. Guárdalo como Interfaz si es una relación" Debería".

Decidir lo que necesita: solo la aplicación de la política, o la reutilización del código Y la política.

Seguro que es importante entender el comportamiento de la interfaz y la clase abstracta en OOP (y cómo los manejan los lenguajes), pero creo que también es importante entender qué significa exactamente cada término. ¿Puedes imaginar que el comando if no funciona exactamente como el significado del término? Además, en realidad algunos idiomas están reduciendo, aún más, las diferencias entre una interfaz y un resumen... si por casualidad un día los dos términos funcionan casi idénticamente, al menos puedes definirte a ti mismo dónde (y por qué) se debe utilizar cualquiera de ellos.

Si lee algunos diccionarios y otras fuentes, puede encontrar diferentes significados para el mismo término, pero con algunas definiciones comunes. Creo que estos dos significados que encontré en este sitio son muy, muy buenos y adecuados.

Interfaz:

Una cosa o circunstancia que permite que elementos separados y a veces incompatibles se coordinen eficazmente.

Resumen:

Algo que concentra en sí mismo las cualidades esenciales de cualquier cosa más extensa o más general, o de varias cosas; esencia.

Ejemplo:

Compraste un coche y necesita combustible.

Su modelo de automóvil es XYZ, que es de género ABC, por lo que es un automóvil concreto, una instancia específica de un automóvil. Un coche no es un objeto real. De hecho, es un conjunto abstracto de estándares (cualidades) para crear un objeto específico. En resumen, el coche es un clase abstracta , es"algo que concentra en sí mismo las cualidades esenciales de cualquier cosa más extensa o más general".

El único combustible que coincida con la especificación manual del automóvil debe usarse para llenar el tanque del automóvil. En realidad, no hay nada que le restrinja a poner cualquier combustible, pero el motor funcionará correctamente solo con el combustible especificado, por lo que es mejor seguir sus requisitos. Los requisitos dicen que acepta, como otros coches de la misma genre ABC, un conjunto estándar de combustible.

En una vista Orientada a objetos, el combustible para el género ABC no debe declararse como una clase porque no hay combustible concreto para un género específico de automóvil. Aunque su automóvil podría aceptar una clase abstracta de Combustible o Combustible vehicular, debe recordar que solo algunos de los combustibles vehiculares existentes cumplen con la especificación, aquellos que implementan los requisitos en el manual de su automóvil. En resumen, deben implementar la interfaz ABCGenreFuel, que "... permite que elementos separados y a veces incompatibles se coordinen eficazmente " .

Adición

Además, creo que debe tener en cuenta el significado del término clase, que es (del mismo sitio mencionado anteriormente):

Clase:

Un número de personas o cosas consideradas como formando un grupo por razón de atributos, características, cualidades o rasgos comunes; tipo;

De esta manera, una clase (o clase abstracta) debe no representan solo atributos comunes (como una interfaz), sino algún tipo de grupo con atributos comunes. Una interfaz no necesita representar un tipo. Debe representar atributos comunes. De esta manera, creo que las clases y las clases abstractas pueden usarse para representar cosas que no deberían cambiar sus aspectos a menudo, como un ser humano un Mamífero, porque representa algunas clases. Los tipos no deben cambiar tan a menudo.