oop - poo - java difference between interface and abstract class




Interfaz vs clase abstracta(OO general) (20)

Recientemente he tenido dos entrevistas telefónicas en las que me han preguntado sobre las diferencias entre una interfaz y una clase abstracta. He explicado todos los aspectos de ellos 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 falta un punto importante, por favor hágamelo saber.

Interfaz:

Cada método declarado en una interfaz deberá implementarse en la subclase. Solo eventos, delegados, propiedades (C #) y métodos pueden existir 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 al lado de Eventos, Delegados, Propiedades y Métodos. Una clase solo puede implementar una clase abstracta solo debido a la no existencia de herencia múltiple en C #.

  1. Después de todo eso, al entrevistador se le ocurrió la pregunta "¿Qué pasaría si tuviera una clase de resumen con solo métodos abstractos? ¿Cómo sería 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, ¿en qué se diferenciaría de 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 :


  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.
    • Ocultamos a los constructores de la misma. 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 la clase abstracta La relación en este caso es IS-A.

Esta es mi opinión.


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


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 a las que no le importa el tipo de clase que implementa la interfaz (por ejemplo, Height puede ser propiedad de la interfaz y puede ser implementado por Human, Building, Tree. No importa si puede comer , puedes nadar, puedes morir o cualquier cosa ... solo importa una cosa que necesitas para tener Altura (implementación en tu clase)).


Creo que la respuesta que buscan es la diferencia fundamental o OPPS filosófica.

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

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

Por ejemplo. Un Coche y un Camión comparten muchas de las propiedades y comportamientos centrales de una clase abstracta de Automóviles, pero también comparten algunos comportamientos periféricos como Generar escape que incluso clases no automovilísticas como Drillers o PowerGenerators comparten y no necesariamente define un Coche o un Camión. , así que Car, Truck, Driller y PowerGenerator pueden compartir la misma interfaz IExhaust.


Explicaré los detalles de profundidad de la interfaz y la clase abstracta. Si conoce el panorama general de la interfaz y la clase abstracta, entonces la primera pregunta le llegará a la mente cuando deberíamos usar la interfaz y cuándo deberíamos usar la clase abstracta. Así que por favor verifique la explicación de la clase Interfaz y Resumen a continuación

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

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

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

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

    Interfaz

    Cada método por defecto, la interfaz pública de medios abstractos es 100% pura abstracta.

    Resumen

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

    Interfaz

    No podemos declarar interfaz como privada, protegida.

    P. ¿Por qué no estamos declarando a la Interfaz como privada y protegida?

    Porque, por defecto, el método de la interfaz es un resumen público, por lo 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 ...

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

    Resumen

    Estamos contentos de usar con estática pública final privada ... significa que no hay restricciones aplicables en abstracto.

    Interfaz

    Las variables se declaran en la Interfaz como una final estática pública predeterminada, por lo que tampoco somos variables declaradas como privadas, protegidas.

    El modificador volátil tampoco es aplicable en la interfaz porque la variable de la interfaz es, por defecto, la variable final y estática pública predeterminada, no puede cambiar el valor una vez que asigna el valor en variable y una vez que haya declarado 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 es por eso que no utilizamos variable volátil en la interfaz.

    Resumen

    Variable abstracta sin necesidad de declarar final estática pública.

Espero que este artículo sea de utilidad.


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, ya que una interfaz realmente solo describe cómo se utiliza 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).

Más de una interfaz se puede implementar en una clase. Una clase solo puede derivar de una única clase base abstracta. Esto permite la jerarquía polimórfica utilizando interfaces, pero no clases base abstractas. Esto también permite una pseudo-multi-herencia utilizando interfaces.

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

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


Para .Net,

Su respuesta al 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.


Qué tal una analogía: cuando estaba en la Fuerza Aérea, fui a entrenamiento de piloto 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 de tipo avión. Una vez que califiqué, fui piloto (clase abstracta) 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ñé funciones 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 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: interfaz

nota agregada: esto fue pensado como una analogía para ayudar a explicar el concepto, no una recomendación de codificación. Ver los diversos comentarios a continuación, la discusión es interesante.


Si considera que java es un lenguaje OOP para responder a 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 website Oracle proporciona diferencias clave entre la interface y abstract clase abstract .

Considere usar clases abstractas si:

  1. Desea compartir código entre varias clases estrechamente relacionadas.
  2. Usted espera que las clases que extiendan 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. Usted espera que las clases no relacionadas implementen su interfaz. Por ejemplo, muchos objetos no relacionados pueden implementar una interfaz Serializable .
  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 de tipo múltiple.

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

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


Interfaz : debe utilizarse 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. Brinda consistencia mediante una firma específica del contrato.

Contras:

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

Clase abstracta : se debe utilizar donde desee tener algún 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

Herencia
Considera un coche 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 coche

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

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

Clases abstractas

Las clases abstractas son objetos incompletos . Para entenderlo mejor, 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 igual que 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 la unidad como abstracto para indicar que cada hijo heredado debe implementar esta función.
Así que si 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 generará un error.
En resumen ... una clase abstracta es una clase parcialmente incompleta con algunas funciones incompletas, que los hijos herederos deben especificar las suyas.

Interfaces Las interfaces están totalmente incompletas. No tienen propiedades. Solo indican que los hijos herederos son capaces de hacer algo ...
Supongamos que tienes diferentes tipos de teléfonos móviles contigo. Cada uno de ellos tiene diferentes maneras 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. Vamos a representar 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);
}
.....

De este modo, utilizando interfaces en lugar de clases abstractas, el autor de la función que utiliza un Dialable no necesita preocuparse por sus propiedades. Ej: ¿Tiene una pantalla táctil o un teclado de marcación? ¿Es un teléfono fijo fijo o un teléfono móvil? Solo necesitas saber si es dialable; ¿Hereda (o implementa) la interfaz Dialable?

Y lo que es más importante , si algún día cambias el Dialable por otro 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) 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 utilizan comúnmente las interfaces para garantizar la interoperabilidad (uso indistintamente) entre objetos, en la medida en que comparten una función común (al igual que usted 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 única clase padre.

Más información Clases abstractas vs Interfaces


Tipos de interfaz vs. clases base abstractas

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

El tipo de interfaz puede parecer muy similar a una clase base abstracta. Recuerde que cuando una clase está 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 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 adolece de una limitación importante en cuanto a que solo los tipos derivados admiten los miembros definidos por el padre abstracto. Sin embargo, en sistemas de software más grandes, es muy común desarrollar múltiples jerarquías de clases 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 tipos en diferentes jerarquías para soportar 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 la herencia múltiple para las clases. Por lo tanto, si desea crear un MiniVan que sea un Coche y un CloneableType, no podrá hacerlo:

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

Como se puede imaginar, 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 conjunto (escrito en cualquier lenguaje de programación .NET) Como puedes 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 solo método llamado Clone ():

public interface ICloneable
{
object Clone();
}

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

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

Aquí hay algunas pautas que podrían ayudarte:

■■ 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; utilizar 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 a 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 utilizar una relación CAN-DO y definir una interfaz.

■■ Facilidad de uso Es generalmente 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 mucha funcionalidad, por lo que el tipo derivado probablemente necesite solo 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 por ciento correctamente. De hecho, COM sufre 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 a usar un tipo que funciona y está bien probado; A continuación, puede modificar las partes que necesitan modificación.

■■ Creación de versiones Si agrega un método al tipo base, el tipo derivado hereda el nuevo método, comienza con 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 recompilarlo.


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 Abstract a 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. Manténgalo como interfaz si es una relación "debería hacer".

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


1) Una interfaz puede verse como una clase abstracta pura, es lo mismo, pero a pesar de esto, no es lo mismo implementar una interfaz y heredarla 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.


Como ya habrán conseguido los conocimientos teóricos de los expertos, no estoy pasando mucho en repetir palabras a todos aquellos que aquí, en lugar permítanme explicar con un ejemplo sencillo en el que podemos usar / no se puede utilizar Interfacey Abstract class.

Tenga en cuenta 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 autos. Del mismo modo, necesitamos herencia para algunas clases solo, ya que algunas de las propiedades como el Sistema de frenado (ABS, EBD) son aplicables solo para algunos autos.

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

Tenga en cuenta que tenemos una clase separada para cada coches.

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 autos Verna y Cruze (no aplicable para Alto). Aunque ambos usan tecnología de frenado, la "tecnología" es diferente. Así que estamos creando una clase abstracta en la que el método se declarará como abstracto y se debe implementar 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 frenos 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 incluso si el método se implementa 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 múltiples herencias con su propio tipo de tecnologías de frenado con la ayuda de Interface.


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

Una interfaz es un acuerdo . Especifica: "Así es como vamos a hablar unos con otros". No puede tener ninguna implementación porque se supone que no tiene ninguna implementación. Es un contrato. Es como los .harchivos de cabecera 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 completamente. Una clase abstracta sin ninguna implementación es inútil, pero totalmente legal.

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

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.


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


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


Una interfaz define un contrato para un servicio o conjunto de servicios. Proporcionan polimorfismo de manera horizontal, ya 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 sub-cadenas 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 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 pueden ser instanciadas por sí mismas, solo sus subclases pueden ser "nuevas".

C # también permite la herencia de la interfaz, fíjate.





abstract-class