2008-11-27 14 views

Respuesta

20

clases abstractas se utilizan cuando tienen la intención de crear una clase concreta, pero quiere asegurarse de que hay una cierta estado común en todas las subclases o una posible implementación común para algunas operaciones.

Las interfaces no pueden contener ninguna.

+0

Seguiría definiendo la interfaz, incluso si se define una clase abstracta. Hace que su código sea más amigable con las pruebas y menos acoplado a una implementación en particular. – tvanfosson

+0

Sí, por supuesto, acepto un 100%. En mi código, por lo general factorizo ​​la interfaz a la interfaz (que sonaba tonto), y uso la clase abstracta como base para la implementación y el estado estándar. – Uri

+0

Usted dijo: "y use la clase abstracta como base para la implementación estándar y estado Probablemente quiso decir: " y utilice la clase abstracta como base para la "implementación común" y el estado " – Shaw

4

La interfaz de la clase abstracta v/s es un tema que genera mucha curiosidad/interés/confusión para cualquier persona nueva en Java y desea profundizar.

This article proporciona una explicación detallada del tema.

+0

El enlace que proporcionó fue muy útil. Dio un uso claro tanto del resumen como de la interfaz. – Warrior

8

Sí, hay un lugar para las clases abstractas y las interfaces.

Veamos un ejemplo concreto. Veremos cómo hacer un CheckingAccount y SavingsAccount desde un resumen AbstractBankAccount y veremos cómo podemos usar una interfaz para diferenciar los dos tipos de cuentas.

Para empezar, aquí es una clase abstracta AbstractBankAccount:

abstract class AbstractBankAccount 
{ 
    int balance; 
    public abstract void deposit(int amount); 
    public abstract void withdraw(int amount); 
} 

Tenemos el saldo de la cuenta como balance y dos métodos depositwithdraw y que deben ser implementadas por las subclases.

Como podemos ver, una clase abstracta declara la estructura de cómo se deben definir las cuentas bancarias. Como @Uri menciona en su respuesta, hay un estado en esta clase abstracta, que es el campo balance. Esto no sería posible con una interfaz.

Ahora, vamos a subclase AbstractBankAccount para hacer una CheckingAccount

class CheckingAccount extends AbstractBankAccount 
{ 
    public void deposit(int amount) 
    { 
     balance += amount; 
    } 

    public void withdraw(int amount) 
    { 
     balance -= amount; 
    } 
} 

En la presente subclase CheckingAccount, hemos implementado las dos clases abstractas - nada demasiado interesante aquí.

Ahora, ¿cómo podríamos implementar SavingsAccount? Es diferente de un CheckingAccount en que ganará interés. El interés se puede aumentar utilizando el método deposit, pero, una vez más, no es como si el cliente depositara el interés por sí mismo. Por lo tanto, podría ser más claro si tuviéramos otro medio para agregar dinero en una cuenta, específicamente para el interés, por ejemplo, un método accrueInterest.

Podríamos aplicar directamente el método de SavingsAccount, pero podemos tener más tipos de cuentas bancarias que pueden derivarse de interés en el futuro, por lo que es posible que desee hacer una interfaz InterestBearing que tiene el accrueInterest método:

interface InterestBearing 
{ 
    public void accrueInterest(int amount); 
} 

por lo tanto, ahora se puede hacer una clase SavingsAccount que puede ganar el interés implementando la interfaz InterestBearing:

class SavingsAccount extends AbstractBankAccount implements InterestBearing 
{ 
    public void deposit(int amount) 
    { 
     balance += amount; 
    } 

    public void withdraw(int amount) 
    { 
     balance -= amount; 
    } 

    public void accrueInterest(int amount) 
    { 
     balance += amount; 
    } 
} 

ahora bien, si queremos hacer anothe r tipo de cuenta, digamos PremiumSavingsAccount, podemos hacer una subclase de AbstractBankAccount e implementar la interfaz InterestBearing para hacer otra cuenta que devenga intereses.

La interfaz InterestBearing se puede ver como y agrega una característica común a diferentes clases. No tendría sentido tener una característica para tratar el interés en una cuenta de cheques cuando no genera ningún interés.

De hecho, hay lugares para que tanto las clases abstractas como las interfaces coexistan y trabajen juntas en una situación.

0

En general, las interfaces describen la API pública de que el código debe utilizar, mientras que las clases base abstractas se conservan mejor como un detalle de implementación, donde se puede conservar el código o estado común, para reducir la duplicación en cualquier clase de implementación.

Al usar interfaces en su API, es más fácil para las personas (incluido usted) escribir código de prueba en sus clases, ya que puede usar clases de prueba que, por ejemplo, no dependen de recursos externos, o exhibe tipos explícitos de comportamiento malo pero difícil de simular en la vida real.

Así Java proporciona la interfaz de lista, y la clase base abstracta AbstractList de "minimizar el esfuerzo necesario para poner en práctica" la interfaz ...

2

Hay un par de razones por las que podría preferir una clase abstracta sin aplicación a través de una interfaz:

  • Ciertas operaciones imposibles y de instancia pueden ser interceptadas en tiempo de compilación.
  • Tiene la opción de agregar métodos concretos en una versión posterior.
  • Solía ​​haber un beneficio de rendimiento significativo hace muchos años.
  • Desde una perspectiva de seguridad muy poco clara, no puede obtener una clase preexistente para implementar los métodos creando una subclase de la clase preexistente y la clase abstracta.

Pero, por otro lado, la interfaz de la palabra clave Java permite una fuente más limpia.

+0

Gracias amigo. Me dio valiosas ideas sobre mi consulta. – Warrior

Cuestiones relacionadas