Interfaz vs clase abstracta (OO general)


1413

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 :


412
Si bien creo que es importante saber la diferencia entre los dos, esta no es una buena pregunta de entrevista, en mi opinión. A menos que el trabajo fuera escribir un libro sobre temas de OO. Es mejor que no trabajes para esos murciélagos.
Alan

107
@ Alan: En realidad, me gusta esto como una pregunta de entrevista, pero no acosaría a alguien de esta manera al respecto, probablemente lo publicaría más como "¿Dónde elegirías una interfaz sobre una clase base abstracta, al definir una jerarquía? ", o algo similar.
Reed Copsey

11
Tal vez buscaban una respuesta más centrada en el diseño ... aunque, como tú, lo habría tratado como una pregunta técnica.
CurtainDog

16
Buenas diferencias tabulares aquí: mindprod.com/jgloss/interfacevsabstract.html
Rajat_R 01 de

30
@Kave: I insisted you can't have a public variable inside an interface.Creo que la interfaz puede tener una variable pública. De hecho, las variables en la interfaz son automáticamente públicas y finales.
un alumno el

Respuestas:


746

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:


77
Gracias. Creo que como su respuesta menciona estado + una buena descripción general de todo el resto, marco su respuesta como respuesta final. Tienes razón, pedí OO general, ya que mi primer entrevistador pidió OO general, pero como soy un chico de C #, tiendo a olvidar eso. ;-) También gracias por la explicación de C ++, como siempre c ++ es alucinante.
Houman el

66
Creo que un punto clave en la explicación que brindó Michael es que al implementar una interfaz DEBES implementar todos los miembros en la interfaz, pero al heredar de una clase abstracta NO ES REQUERIDO por una clase hija implementar los miembros de sus padres
Guillermo Gómez

82
+1: estaría dispuesto a apostar a que los monos que acogen la entrevista ni siquiera se dan cuenta de que otros idiomas implementan OO de manera diferente.
Carreras de ligereza en órbita el

2
@JL No veo dónde radica el problema. Parece que has confundido el método abstracto con la clase abstracta. Los métodos abstractos no tienen implementación. Sin embargo, dentro de una clase abstracta , algunos métodos pueden ser abstractos (es decir, sin implementación) mientras que otros pueden tener implementación.
xji

19
Tenga en cuenta que en Java 8, ahora puede tener métodos predeterminados y métodos estáticos en las interfaces, lo que significa que las interfaces Java pueden tener implementación. La referencia aquí . Obviamente te referiste principalmente a .NET, así que esto es solo una observación que se refiere a Java.
davtom 01 de

867

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


87
Esta analogía me gusta mucho, usa un ejemplo simple para explicar un tema un poco complejo
Kevin Bowersox,

13
Esta es la mejor manera de entender la terminología OO compleja. En resumen, toda teoría vale solo cuando puedes usarla prácticamente. @ Jay, re-muestrear es realmente fácil de entender y luego varios puntos de bala (¡sobre todo una mente penetrante en lugar de ser absorbida!)
vs

54
Todavía estoy un poco confundido. Digamos que ahora obtuviste las calificaciones F-16 y T-38, por lo que ahora la clase Jayno puede heredar de múltiples clases (piloto C-141, piloto F-16 y piloto T-38), ¿eso significa que cuyas clases deberían convertirse en interfaces? Gracias
Alex Okrushko

37
Mucha gente ha dado acertadamente un +1 al comentario de Alex, ya que revela cierta debilidad en este ejemplo. Primero, diría que Jay sería una instancia de C-141Pilot en lugar de su propia clase. Además, dado que en la USAF el 99% de todos los pilotos solo están calificados en un avión a la vez (FCF y los pilotos de prueba son excepciones notables) No consideré múltiples calificaciones y cómo podría implementarse. Como sé de un piloto que, hace 50 años, estaba calificado en 25 aviones diferentes simultáneamente, creo que eso ejemplifica cómo NO queremos usar la herencia múltiple.
Jay

20
Dado que es poco probable que un piloto vuele más de un avión a la vez, sería una buena oportunidad para implementar el patrón de estrategia. Un piloto tendría una colección de certificaciones y seleccionaría la correcta en tiempo de ejecución. Las certificaciones se codificarían como comportamientos que implementarían la interfaz IFlyPlane, con métodos TakeOff, Land, Eject.
Michael Blackburn

221

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.


32
Creo que una analogía aún mejor sería "usesFuel", que mostraría la naturaleza contractual de la interfaz.
Pureferret

@Pureferret si acceleratees parte del comportamiento central de la clase abstracta de automóviles, entonces no puedo decir que acceleratemuestra la naturaleza del contrato . ¿Qué es la naturaleza del contrato? ¿Por qué esta palabra se contractpresenta cada vez que hablamos interface?
intercambio excesivo el

@overexchange porque normalmente la interfaz es justo donde se encuentran dos 'superficies', pero la palabra contrato implica que hay un acuerdo sobre cómo se encuentran las dos 'superficies'. No tiene sentido (al menos para mí) que generar escape es algo en lo que 'está de acuerdo'. Pero tiene sentido (de nuevo para mí) que puede ponerse de acuerdo sobre la necesidad de usar Fuel.
Pureferret

1
@Pureferret planteé una consulta en el enlace para el mismo
sobreexchange

1
@Pureferret si interfacenecesita tener un comportamiento periférico, entonces ¿por qué public interface List<E> extends Collection<E> {}está diseñado para describir el comportamiento central de list? Esto en realidad está contradiciendo la respuesta de Prasun. Ambos Collection<E>y List<E>son interfaces aquí.
intercambio excesivo el

198

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


77
Realmente me gusta esta respuesta porque a veces es difícil responder al "qué" es diferente entre las cosas mirando algo más abstracto como la intención , en lugar de solo la estructura (como estructuralmente, una interfaz y una clase abstracta pura son más o menos lo mismo cosa).
LostSalad

Es fácil enumerar lo que una clase abstracta frente a una interfaz puede hacer en un lenguaje específico, pero es más difícil crear una abstracción para dar significado y responsabilidad a los objetos y lo que usted dijo reanudará totalmente el uso del concepto 2 en OO. ¡Gracias!
Samuel

2
@dhananjay: veo cómo la Altura puede separarse del concepto de la clase Animal y puede ser de otra clase diferente, pero ¿qué quieres decir exactamente con "comunicación" entre las clases? Es simplemente definir Altura para su propia clase, ¿correcto?
TTT

77

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.


55
+1 para el punto clave de que se puede implementar más de una interfaz en una clase.
cgp

Esa es la única ventaja real de las interfaces sobre las clases base abstractas, IMO. De lo contrario, estoy de acuerdo con las pautas de diseño .NET, que ahora dicen "preferir las clases base abstractas a las interfaces"
Reed Copsey

Sin embargo, sería interesante si pudiera agregar el punto de que también las interfaces se pueden aplicar a cualquier clase.
cgp

1
@altCognito: Supuse que se manejaba con el segundo párrafo. Sin embargo, esto me recordó que las interfaces funcionan en tipos de valor, así que agregué eso.
Reed Copsey

Muchas gracias por esta descripción exacta. De hecho es muy útil. Soy nuevo aquí. Es una pena que no pueda seleccionar dos respuestas como "respuesta". Una cosa que me confunde es su uso de la clase abstracta 'base'. Todas las clases abstractas están destinadas a ser una clase base de una subclase. ¿Por qué nombrar el extra 'base'?
Houman

68

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


No es cierto que "las interfaces no tienen ninguna propiedad".
Bigeyes

@Bigeyes, Java no permite propiedades en las interfaces. Pensé que era igual en otros idiomas también. ¿Podría por favor explicar más?
fz_salam

Me refiero a C # /. Net. Por favor vea el ejemplo
Bigeyes

@Bigeyes para C # donde las interfaces pueden tener propiedades, ¿eso no reintroduce el problema de herencia múltiple? ¿Qué sucede cuando una clase usa múltiples interfaces que han definido la misma propiedad? Simplemente curioso gracias
stackPusher

@happycoder: re: "Aquí, mediante el uso de interfaces en lugar de clases abstractas, 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 es dialable; ¿hereda (o implementa) la interfaz Dialable? " - ¿puede mostrar esto en un ejemplo de código, tampoco vi cómo se heredaría ...
TTT

45

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?


33

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.


Me hicieron la misma pregunta hace una semana, no tengo experiencia con Java, pero he estado trabajando con C ++ por un tiempo. El entrevistador no especificó idiomas antes de hacer la pregunta, así que simplemente le expliqué que las interfaces en este caso eran clases abstractas sin estado o implementaciones de ningún tipo. Estoy de acuerdo en que también es una pregunta extraña.
dacabdi

31

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.


17
Las interfaces logran, en mi opinión, más de una relación "Act-as-a". La encapsulación logra la composición mejor que una interfaz.
Reed Copsey

12
No creo que la implementación de interfaces esté bajo composición.
Pavan Dittakavi

Además, es más probable que la interfaz use para describir la "capacidad", como IDisposable. Solía ​​compartir la funcionalidad entre clases que estas clases "pueden hacer" algo. Más ejemplo IFlyable puede implementarse por pájaro y avión. Pero Bird puede derivar de Class Creature, donde las aeronaves derivan de AirCraft.
Peter.Wang

26

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.


44
No estoy de acuerdo con este punto: Abstract class must have at lease one abstract method.ES posible tener una clase Abstract sin un método Abstract, siempre que lo implemente. REFERENCIA: An abstract class is a class that is declared abstract—it may or may not include abstract methods.FUENTE DE REFERENCIA: docs.oracle.com/javase/tutorial/java/IandI/abstract.html
Devner

Estás hablando de detalles técnicos y de implementación, no estás respondiendo la pregunta en términos de OOP general
Billal Begueradj

26

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?


Eso resume bastante bien la respuesta a esta pregunta.
pranavn

Funcionalidad implementada vs estructura extendida, ¡agradable!
harshvchawla

21

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.


2
¡Si! ¡Estado! A eso se refería el segundo entrevistador con su extraña forma de decir "variable pública" dentro de una interfaz. ¡Dios mio! ¡Las clases abstractas pueden tener estado, las interfaces no pueden! Y sí, todos los demás también están de acuerdo en las diferencias entre sus formas de herencia, que olvidé mencionar pero descubrí más tarde. :) ¡Gracias a todos!
Houman el

44
Más que solo estado ... Las clases abstractas pueden tener IMPLEMENTACIÓN. es decir, pueden tener métodos con código en ellos que realmente se ejecutan y hacen algo, que se hereda y ejecuta por instancias de las clases base ... No es así con las interfaces
Charles Bretana

Incluso más que eso, en un sentido, las clases abstractas PUEDEN ser instanciadas, solo tienen que ser instanciadas usando una definición de clase derivada, no directamente. Pero las variables de estado definidas en la clase abstracta se instancian en el objeto creado al actualizar una instancia de la clase derivada. Esta instancia ES una instancia de la clase abstracta además de ser una instancia de la clase derivada; después de todo, se deriva de ella. Nada de esto es cierto para una interfaz.
Charles Bretana

Cuando actualiza una instancia de una clase definida para implementar una interfaz, no es una "instancia" de esa interfaz, toda la sintaxis hace que el compilador examine el código de la clase y se asegure de que cada comportamiento (método, propiedad , event, eventHandler, etc.) que se define por la interfaz se ha implementado en el código de la clase.
Charles Bretana

20

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

Define más rápido. ¿Es significativo? ¿Qué se supone que significa eso? opcode para invocar funciones en una clase abstracta es más rápido que opcode para invocar funciones en una interfaz?
denis631

@ denis631 la clase abstracta es ligeramente más rápida que la interfaz debido a que la búsqueda y la llamada están involucradas dentro del método de la interfaz. lea este coderanch.com/t/503450/java/abstract-class-faster-interface
bourax webmaster

17

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


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


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


12

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.


1
@AbdullahShoaib es-a y cualquiera puede hacer, pero no puede hacer, hay una diferencia aquí. Esta es la razón básica, necesitamos interfaz. el comportamiento que puede hacer también formará parte abstract class.
intercambio excesivo el

10

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.


1
El uso de los términos horizontal y vertical dejó muy claro imaginar la diferencia.
Infinity

10

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.


10

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.


44
Esta es una de las mejores explicaciones debido a los ejemplos.
Adam Mendoza

2
Esto tiene sentido para mí sin atormentar el cerebro. Solo estaba tratando de encontrar un ejemplo de auto para mis alumnos. Gracias por dedicar tiempo para armar esto.
tazboy

9

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


8

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.


7

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.


7

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.


1
Creo que quiere decir que una herramienta DI puede inyectar una clase que implementa una interfaz. Algunas de estas herramientas también pueden inyectar clases derivadas de una clase abstracta, ¿o estás diciendo que eso es imposible?
John Saunders

6

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.


6

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

6

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


6

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.

ingrese la descripción de la imagen aquí

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.


1
demasiada pelusa, no hagas que suene más confuso para las personas de lo que ya puede ser.
ganjeii

5

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.


3

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.


en Java, la interfaz puede tener una variable miembro, pero por defecto se vuelven públicas estáticas ... por lo que la interfaz puede tener campos estáticos
Jitendra Vispute

Sí, la interfaz puede tener campos estáticos. PERO la interfaz no puede tener métodos estáticos.
un alumno el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.