Interfaz vs clase abstracta (OO general)

Recientemente tuve dos entrevistas telefónicas donde me preguntaron sobre las diferencias entre una interfaz y una clase abstracta. Les he explicado todos los aspectos que se me ocurren, pero parece que están esperando que mencione algo específico, y no sé qué es.

Desde mi experiencia, creo que lo siguiente es cierto. Si me estoy perdiendo un punto importante, hágamelo saber.

Interfaz:

Cada método declarado en una interfaz deberá implementarse en la subclase. Solo pueden existir eventos, delegados, propiedades (C #) y métodos en una interfaz. Una clase puede implementar múltiples interfaces.

Clase abstracta:

Solo los métodos abstractos deben 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 herencia múltiple en C #.

1. Después de todo eso, al entrevistador se le ocurrió la pregunta "¿Qué pasaría si tuvieras una clase abstracta 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, ¿verdad?

2. Otro entrevistador me preguntó qué pasaría si tuviera una variable pública dentro de la interfaz, ¿cómo sería eso diferente a la clase abstracta? Insistí en que no puedes tener una variable pública dentro de una interfaz. No sabía lo que quería escuchar, 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 decides 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 .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 estado (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 de herencia múltiple, las clases abstractas pueden no serlo (esta es probablemente la razón concreta clave 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 programadores de C ++ que pueden tener definiciones rígidas similares (las interfaces son un subconjunto estricto de clases abstractas que no pueden contener implementación), mientras que algunos pueden decir que una clase abstracta con algunas implementaciones predeterminadas sigue siendo una interfaz o que una no abstracta La clase aún puede definir una interfaz.

De hecho, hay un idioma de C ++ llamado Interfaz no virtual (NVI) donde los métodos públicos son métodos no virtuales que 'enlazan' con los métodos virtuales privados:

• http://www.gotw.ca/publications/mill18.htm
• http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtual_Interface

¿Qué tal una analogía? Cuando estaba en la Fuerza Aérea, fui al entrenamiento de pilotos y me convertí en piloto de la Fuerza Aérea de los EE. UU. En ese momento no estaba calificado para volar nada, y tuve que asistir a un entrenamiento tipo avión. Una vez que califiqué, fui piloto (clase Resumen) y piloto C-141 (clase concreta). En una de mis tareas, me dieron un deber adicional: Oficial de seguridad. Ahora todavía era piloto y piloto C-141, pero también desempeñé tareas de oficial de seguridad (implementé ISafetyOfficer, por así decirlo). 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 toda 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 seguridad de IS: interfaz

Nota agregada: se suponía que era una analogía para ayudar a explicar el concepto, no una recomendación de codificación. 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 u OPPS.

La herencia de clase abstracta se usa cuando la clase derivada comparte las propiedades y el comportamiento centrales 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 ej. Un automóvil y un camión comparten muchas propiedades y comportamientos centrales de una clase abstracta de automóviles, pero también comparten un comportamiento periférico como Generar gases de escape que incluso las clases que no son automóviles como Drillers o PowerGenerators comparten y no necesariamente definen 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 utilizan para modelar una jerarquía de clases de clases de aspecto similar (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 que no se preocupan por el tipo de interfaz que implementa la clase (por ejemplo, la altura puede ser propiedad de la interfaz y puede ser implementada por humanos, edificios, árboles. No importa si puede comer , puedes nadar, puedes morir o cualquier cosa ... solo importa algo que necesites 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 realmente proporcione 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 le da 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-herencia múltiple usando interfaces.

Las clases base abstractas se pueden modificar en v2 + sin romper la API. Los cambios en las interfaces son cambios importantes.

Las interfaces [C # / .NET específicas], a diferencia de las clases base abstractas, se pueden aplicar a los 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 valor.

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

public class Vehicle {
    private Driver driver;
    private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections).
    //You can define as many properties as you want here ...
}

Ahora una bicicleta ...

public class Bicycle extends Vehicle {
    //You define properties which are unique to bicycles here ...
    private Pedal pedal;
}

Y un auto ...

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

Eso es todo sobre herencia . Los usamos para clasificar objetos en formas básicas más simples y sus hijos como vimos anteriormente.

Clases abstractas

Las clases abstractas son objetos incompletos . Para entenderlo más, consideremos la analogía del vehículo una vez más.
Un vehículo puede ser conducido. ¿Derecha? Pero los diferentes vehículos se manejan de diferentes maneras ... Por ejemplo, no puede conducir un automóvil tal como conduce una bicicleta.
Entonces, ¿cómo representar la función de conducción de un vehículo? Es más difícil verificar qué tipo de vehículo es y conducirlo con su propia función; tendría que cambiar la clase de Conductor una y otra vez al agregar un nuevo tipo de vehículo.
Aquí viene el papel de las clases y métodos abstractos. Puede definir el método de unidad como abstracto para indicar que todos los elementos secundarios heredados deben implementar esta función.
Entonces, si modifica la clase de vehículo ...

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

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

Interfaces Las interfaces son totalmente incompletas. No tienen ninguna propiedad. Solo indican que los hijos herederos son capaces de hacer algo ...
Supongamos que tiene diferentes tipos de teléfonos móviles con usted. Cada uno de ellos tiene diferentes formas de hacer diferentes funciones; Ej: llamar a una persona. El fabricante del teléfono especifica cómo hacerlo. Aquí los teléfonos móviles pueden marcar un número, es decir, se puede marcar. Representemos esto como una interfaz.

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

Aquí el creador de Dialable define cómo marcar un número. Solo necesita darle un número para marcar.

// Makers define how exactly dialable work inside.

Dialable PHONE1 = new Dialable() {
    public void dial(Number n) {
        //Do the phone1's own way to dial a number
    }
}

Dialable PHONE2 = new Dialable() {
    public void dial(Number n) {
        //Do the phone2's own way to dial a number
    }
}


//Suppose there is a function written by someone else, which expects a Dialable
......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE1;
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

Mediante el uso de interfaces en lugar de clases abstractas, el escritor de la función que utiliza un Dialable no necesita preocuparse por sus propiedades. Ej: ¿Tiene una pantalla táctil o teclado de marcación? ¿Es un teléfono fijo o un teléfono móvil? Solo necesita saber si se puede marcar; ¿Hereda (o implementa) la interfaz Dialable?

Y lo más importante , si algún día cambias el Dialable por uno diferente

......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

Puede estar seguro de que el código aún funciona perfectamente porque la función que usa el marcado no depende (y no puede) de los detalles que no sean los especificados en la interfaz Marcable. Ambos implementan una interfaz Dialable y eso es lo único que le importa a la función.

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

Más información Clases abstractas vs Interfaces

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

El sitio web de Oracle proporciona diferencias clave entre interfacey la abstractclase.

Considere usar clases abstractas si:

1. Desea compartir código entre varias clases estrechamente relacionadas.
2. Espera que las clases que extienden su clase abstracta tengan muchos métodos o campos comunes, o 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. Espera que clases no relacionadas implementen su interfaz. Por ejemplo, muchos objetos no relacionados pueden implementarSerializable interfaz.
2. Desea especificar el comportamiento de un tipo de datos en 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: para implementar un contrato por varios objetos no relacionados

clase abstracta: para implementar el mismo comportamiento o diferente entre varios objetos relacionados

Eche un vistazo al ejemplo de 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, hay una diferencia, pero en otros lenguajes como C ++ no la hay. 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án. Las interfaces generalmente no tienen ninguna implementación sino solo funciones virtuales puras.

En C # o Java, una clase abstracta sin ninguna 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.

Al implementar interfaces, está logrando 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 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 Resumen. Si conoce una descripción general sobre la interfaz y la clase abstracta, entonces la primera pregunta le viene a la mente cuándo debemos usar la interfaz y cuándo debemos usar la clase Resumen. Por lo tanto, compruebe a continuación la explicación de la clase Interfaz y Resumen.

1. ¿Cuándo debemos usar la interfaz?

   Si no conoce la implementación, solo tenemos la especificación de requisitos, entonces vamos con la interfaz

2. ¿Cuándo debemos usar la clase abstracta?

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

   Interfaz

   todos los métodos por defecto resumen público significa que la interfaz es 100% puro resumen.

   Resumen

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

   Interfaz

   No podemos declarar la interfaz como privada, protegida

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

   Porque, por defecto, el método de la interfaz es público abstracto, por lo que no declaramos que la interfaz sea privada y protegida.

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

   Daré la razón: por qué no estamos declarando el método sincronizado porque no podemos crear el objeto de la interfaz y sincronizar estamos trabajando en el objeto, por lo que no estamos declarando el método sincronizado El concepto transitorio tampoco es aplicable porque el trabajo transitorio está sincronizado.

   Resumen

   estamos felices de usar 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 variable como privada, protegida.

   El modificador volátil tampoco es aplicable en la interfaz porque la variable de interfaz es por defecto pública estática variable final y final, no puede cambiar el valor una vez que asigna el valor a 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. Para finalizar, esa es la razón por la que no utilizamos variables volátiles en la interfaz.

   Resumen

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

Espero que este artículo sea útil.

Hablando conceptualmente, mantener la implementación específica del lenguaje, las reglas, los beneficios y lograr cualquier objetivo de programación mediante el uso de cualquiera o ambos, puede o no tener código / datos / propiedad, bla, bla, herencias únicas o múltiples, todo aparte

1- Resumen (o resumen abstracto) La clase está destinada a implementar jerarquía. Si sus objetos de negocio se ven estructuralmente similares, representando un tipo de relación padre-hijo (jerarquía) solo entonces se usarán las clases herencia / Resumen. Si su modelo de negocio no tiene una jerarquía, entonces no debe usarse la herencia (aquí no estoy hablando de lógica de programació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 las interfaces, en realidad comparar la clase abstracta con la interfaz no tiene sentido porque ambas son cosas conceptualmente totalmente diferentes, se solicita en entrevistas solo para verificar los conceptos porque parece que ambos proporcionan la misma funcionalidad cuando se trata de la implementación y los programadores generalmente enfatizamos más en la codificación. [Tenga esto en cuenta también que la abstracción es diferente a la clase abstracta].

2- una interfaz es un contrato, una funcionalidad comercial completa representada por una o más funciones. Por eso se implementa y no se hereda. Un objeto comercial (parte de una jerarquía o no) puede tener cualquier cantidad de funcionalidad comercial completa. No tiene nada que ver con 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 diferente jerarquía implementarían la interfaz EJECUTAR o la interfaz COMER o HABLAR. No entre en la implementación, ya que podría implementarla como 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.

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

Cuando se le pregunta sobre la diferencia, en realidad es una diferencia conceptual, no la diferencia en la implementación específica del lenguaje, a menos que se le pregunte explícitamente.

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

¿Qué pasaría si tuvieras 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 el estado AND, 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.

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

Pros:

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

Contras:

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

Clase abstracta : debe usarse donde desea tener un comportamiento básico o predeterminado o implementación para componentes relacionados entre sí

Pros:

1. Más rápido que la interfaz
2. Tiene flexibilidad en la implementación (puede implementarla total o parcialmente)
3. Se puede cambiar fácilmente sin romper las clases derivadas

Contras:

1. No puede ser instanciado
2. No admite herencia múltiple

Creo que no les gustó su respuesta porque usted dio las diferencias técnicas en lugar de las de diseño. La pregunta es como una pregunta troll para mí. De hecho, las interfaces y las clases abstractas tienen una naturaleza completamente diferente, por lo que realmente no se pueden comparar. 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 utiliza para garantizar 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 algún 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 debe manejar muchas responsabilidades (use composición lugar).

Por lo tanto, 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 doctores 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 public static y final. La pregunta podría enmarcarse como si todas las variables en la clase abstracta fueran públicas. Bueno, todavía pueden ser no estáticos y no finales a diferencia de las variables en las interfaces.

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

1. Interfaz:
   • No implementamos (o definimos) métodos, lo hacemos en clases derivadas.
   • No declaramos variables miembro en las 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 a partir de él directamente.
   • La clase abstracta puede contener variables miembro.
   • Las clases derivadas heredan a la clase abstracta que significa que los objetos de las clases derivadas no están enmascarados, sino que heredan a la clase abstracta. La relación en este caso es IS-A.

Esta es mi opinión.

Copiado de CLR a través de C # por Jeffrey Richter ...

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

Aquí hay algunas pautas que pueden ayudarlo:

■■ Relación IS-A vs. CAN-DO Un tipo puede heredar solo una implementación. Si el tipo derivado no puede reclamar una relación IS-A con el tipo base, no use un tipo base; Usa una interfaz. Las interfaces implican una relación CAN-DO. Si la funcionalidad CAN-DO parece pertenecer a varios tipos de objetos, use una interfaz. Por ejemplo, un tipo puede convertir instancias de sí mismo en otro tipo (IConvertible), un tipo puede serializar una instancia de sí mismo (ISerializable), etc. Tenga en cuenta que los tipos de valor deben derivarse de System.ValueType y, por lo tanto, no pueden derivarse de una clase base arbitraria. En este caso, debe usar una relación CAN-DO y definir una interfaz.

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

■■ Implementación consistente No importa qué tan bien esté documentado un contrato de interfaz, es muy poco probable que todos implementen el contrato al 100% correctamente. De hecho, COM sufre este mismo problema, por lo que algunos objetos COM funcionan correctamente solo con Microsoft Word o Windows Internet Explorer. Al proporcionar un tipo base con una buena implementación predeterminada, comienza usando un tipo que funciona y está bien probado; entonces puede modificar las partes que necesitan modificación.

■■ Control de versiones Si agrega un método al tipo base, el tipo derivado hereda el nuevo método, comienza a usar un tipo que funciona y el código fuente del usuario ni siquiera tiene que volver a compilarse. Agregar un nuevo miembro a una interfaz obliga al heredero de la interfaz a cambiar su código fuente y volver a compilar.

Una interfaz define un contrato para un servicio o conjunto de servicios. Proporcionan polimorfismo de manera horizontal en el sentido de que dos clases completamente no relacionadas pueden implementar la misma interfaz, pero se pueden usar 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 subcapas y, opcionalmente, una implementación parcial. Las clases abstractas proporcionan polimorfismo de una manera vertical, pero direccional, en el sentido de que cualquier clase que herede la clase abstracta puede tratarse 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 se pueden instanciar por sí solas, solo sus subclases se pueden "actualizar".

C # también permite la herencia de la interfaz.

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

Una interfaz es un acuerdo . Especifica: "así es como vamos a hablar entre nosotros". No puede tener ninguna implementación porque se supone que no debe tener ninguna implementación. Es un contrato. Es como los .harchivos de encabezado 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 implementarla por completo. 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: Animalpodría ser una clase abstracta que implementa algunas funciones metabólicas básicas y especifica métodos abstractos para respirar y locomoción sin dar una implementación, porque no tiene idea de si debe respirar por las branquias o los pulmones, y si vuela, nada, camina o se arrastraMount, por otro lado, podría ser una interfaz, que especifica que puede montar el animal, sin saber qué tipo de animal es (¡o si es un animal en absoluto!).

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

Como es posible que haya obtenido el conocimiento teórico de los expertos, no estoy gastando muchas palabras en repetir todo eso aquí, más bien déjeme explicar con un simple ejemplo dónde podemos usar / no podemos usar Interfacey Abstract class.

Considere que está diseñando una aplicación para enumerar todas las características de Cars. 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 automóviles. Del mismo modo, necesitamos herencia para algunas clases solo ya que algunas de las propiedades como el sistema de frenos (ABS, EBD) son aplicables solo para algunos automóviles.

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

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

Considere que necesitamos un método para heredar la tecnología de frenado para los automóviles Verna y Cruze (no aplicable para Alto). Aunque ambos usan tecnología de frenado, la "tecnología" es diferente. Por lo tanto, estamos creando una clase abstracta en la que el método se declarará como Resumen y debería implementarse 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";
    }         
}

¿Ves el problema en las dos clases anteriores? Heredan de varias clases que C # .Net no permite aunque el método se implemente en los hijos. Aquí viene la necesidad de la interfaz.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

Y la implementación se da a continuación:

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.

Estas respuestas son demasiado largas.

• Las interfaces son para definir comportamientos.

• Las clases abstractas son para definir una cosa en sí, incluidos sus comportamientos. Es por eso que a veces creamos una clase abstracta con algunas propiedades adicionales que heredan una interfaz.

Esto también explica por qué Java solo admite la herencia única para las clases, pero no impone restricciones a las interfaces. Porque un objeto concreto no puede ser cosas diferentes, pero puede tener comportamientos diferentes.

1) Una interfaz puede verse como una clase abstracta pura, es la misma, 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 esa 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 agregar otro punto a favor de las interfaces:

Las interfaces se pueden inyectar usando cualquier herramienta de Inyección de dependencias, mientras que la inyección de clase abstracta es compatible con muy pocas.

De otra respuesta mía , principalmente sobre cuándo usar uno versus el otro:

En mi experiencia, las interfaces se utilizan mejor cuando tiene varias clases, cada una de las cuales necesita responder al mismo método o métodos para que puedan ser utilizados indistintamente por otro código que se escribirá en la interfaz común de esas clases. El mejor uso de una interfaz es cuando el protocolo es importante pero la lógica subyacente puede ser diferente para cada clase. Si de lo contrario estaría duplicando la lógica, considere las clases abstractas o la herencia de clase estándar.

Tipos de interfaz versus clases base abstractas

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

El tipo de interfaz puede parecer muy similar a una clase base abstracta. Recuerde que cuando una clase se marca 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 miembros abstractos, también es libre de definir cualquier número de constructores, datos de campo, miembros no abstractos (con implementación), etc. Las interfaces, por otro lado, contienen solo definiciones de miembros abstractos. La interfaz polimórfica establecida por una clase padre abstracta sufre una limitación importante, ya que solo los tipos derivados son compatibles con los miembros definidos por el padre abstracto. Sin embargo, en sistemas de software más grandes, es muy común desarrollar jerarquías de clases múltiples que no tienen un padre común más allá de System.Object. Dado que los miembros abstractos en una clase base abstracta se aplican solo a los tipos derivados, no tenemos forma de configurar los tipos en diferentes jerarquías para admitir la misma interfaz polimórfica. A modo de ejemplo, suponga 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 pueden admitir el método Clone (). Si crea un nuevo conjunto de clases que no extienden esta clase base, no puede obtener esta interfaz polimórfica. Además, puede recordar que C # no admite herencia múltiple para clases. Por lo tanto, si desea crear un MiniVan que sea un Auto y un CloneableType, no puede hacerlo:

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

Como es de suponer, los tipos de interfaz vienen al rescate. Una vez que se ha definido una interfaz, puede ser implementada 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, definida en el espacio de nombres del sistema. Esta interfaz define un único método llamado Clone ():

public interface ICloneable
{
object Clone();
}

Responda a la segunda pregunta: la publicvariable definida en interfacees static finalpor defecto, mientras que la publicvariable en abstractclase es una variable de instancia.

Sin duda, es importante comprender el comportamiento de la interfaz y la clase abstracta en OOP (y cómo los manejan los idiomas), pero creo que también es importante comprender qué significa exactamente cada término. ¿Te imaginas elif comando 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 algún día los dos términos operan casi de manera idéntica, al menos puede definirse dónde (y por qué) debe ser alguno de ellos usado para.

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 realmente buenos y adecuados.

Interfaz:

Una cosa o circunstancia que permite que elementos separados ya veces incompatibles se coordinen de manera efectiva.

Resumen:

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

Ejemplo:

Usted compró un automóvil 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 automóvil no es un objeto real. De hecho, es un conjunto abstracto de estándares (cualidades) para crear un objeto específico. En resumen, Car es una clase abstracta , es "algo que concentra en sí mismo las cualidades esenciales de algo más extenso o más general" .

El único combustible que coincide con la especificación manual del automóvil debe usarse para llenar el tanque del automóvil. En realidad, no hay nada que lo limite a poner 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 autos del mismo género.ABC , un conjunto estándar de combustible.

En una vista orientada a objetos, el combustible por género ABCno 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 un combustible de clase abstracta o combustible para vehículos, debe recordar que solo algunos de los combustibles para vehículos existentes cumplen con las especificaciones, aquellos que implementan los requisitos en el manual de su automóvil. En resumen, deberían implementar la interfaz ABCGenreFuel , que "... permite que elementos separados ya veces incompatibles se coordinen de manera efectiva" .

Apéndice

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 en razón de atributos, características, cualidades o rasgos comunes; tipo;

De esta manera, una clase (o clase abstracta) no debe representar 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 algunos tipos. Los tipos no deberían cambiarse tan a menudo.

Desde la perspectiva de 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 se perderá la reutilización del código que proporciona Inheritance.

Desde la perspectiva del diseño

Manténgalo como una clase abstracta si es una relación "Es un" y necesita un subconjunto o toda la funcionalidad. Manténgalo como interfaz si se trata de una relación "debería hacerlo".

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

Un par de otras diferencias:

Las clases abstractas pueden tener métodos estáticos, propiedades, campos, etc. y operadores, las interfaces no. El operador de transmisión permite la conversión a / desde la clase abstracta, pero no permite la conversión a / desde la interfaz.

Por lo tanto, puede usar la clase abstracta por sí misma incluso si nunca se implementa (a través de sus miembros estáticos) y no puede usar la interfaz por sí sola de ninguna manera.