icon - Java porque la interfaz extiende la interfaz

java gui framework

Question

Me pregunto en qué circunstancias extendemos una interfaz desde una interfaz. Porque, por ejemplo,

interface A{
public void method1();
}
interface B extends A{
public void method2();
}
class C implements B{
@Override public void method1(){}
@Override public void method2(){}
}

No es equivalente a

interface A{
public void method1();
}
interface B{
public void method2();
}
class C implements A, B{
@Override public void method1(){}
@Override public void method2(){}
}

¿Hay alguna razón significativa detrás?

Answer 1

La principal diferencia aquí es que en tu primer ejemplo B es A y luego algo. Eso significa que la Interfaz B llama a method1 () y method2 (), donde como en la segunda A y B están separados (la interfaz B NO concluye method1 ()) y la clase C implementa A y B. En ambos intentos, la Clase C anulará el método () y method2 (). ¡Espero que esto ayude!

Answer 2

Las razones importantes dependen completamente de lo que se supone que debe hacer la interfaz.

Si tiene una interfaz de vehículo y una interfaz manejable, es lógico que todos los vehículos sean manejables. Sin herencia de interfaz, cada clase diferente de automóvil va a requerir

class ChevyVolt implements Vehicle, Drivable
class FordEscort implements Vehicle, Drivable
class ToyotaPrius implements Vehicle, Drivable

y así.

Como dije, todos los vehículos son manejables, así que es más fácil tener:

class ChevyVolt implements Vehicle
class FordEscort implements Vehicle
class ToyotaPrius implements Vehicle

Con vehículo de la siguiente manera:

interface Vehicle extends Drivable

Y no hay que pensarlo.

Answer 3

Lo que está diciendo es correcto, pero no se trata solo de hacer nuestro trabajo, si el requisito es así:

1) Imagina que hay 10 interfaces, no diseñadas al mismo tiempo. Por ejemplo, la interfaz AutoCloseable en Java 7. Se agregó una nueva característica de cierre automático, no estaba allí hasta Java 6.

2) Si diseñó una interfaz C que es una interfaz de marcador y desea que se marquen todas las clases derivadas de una clase B dada, la mejor solución sería utilizar B extiende C y no ir y poner los implementos C en todas partes.

Hay muchas más razones. Si observa la imagen más grande de las clases y la jerarquía, puede obtener la respuesta usted mismo.

Feliz de ayudar a Dharam

Answer 4

Sí hay: es como herencia en cualquier otro lugar. Si B es una especialización de A, entonces debería escribirse de esa manera. El segundo indica que la clase simplemente implementa 2 interfaces sin relación entre ellas.

Desde el punto de vista del resultado final, podría usar múltiples interfaces en lugar de manejar una jerarquía (al igual que podría evitar el uso de comportamientos heredados en una jerarquía de clases). Esto dejaría la información más dispersa, sin embargo, y como (si no más) confunde significativamente la intención del modelo de software.

Answer 5

Sí, hay una gran diferencia.

En su primer ejemplo, su nueva interfaz B está definida para extenderse desde A, así que en el futuro, cualquier clase que implemente B implementa automáticamente A. Básicamente, le está diciendo al compilador "esto es lo que significa ser una A, esto es lo que significa ser una B, y por cierto, ¡todas las B son también las A ! " Eso te permite decir cosas como ...

class C implements B {
... you implement all of the methods you need...
...blah...
...blah...
}
A myNewA = new C();

y eso funciona bien.

Pero, en su segundo ejemplo, no declara que B extienda A, por lo que el código anterior no funcionaría. Cuando intenta asignar una instancia de (el segundo tipo de) C en una referencia para A, se quejaría, porque no le ha dicho al complaciente que "todos los B son en realidad A". (es decir, no hay relación entre B y C )

Answer 6

Si no desea que B se implemente sin implementar A, puede hacer que B se extienda A.

Ejemplo:

interface LivingThing{
public void eat();
}
interface Dog extends LivingThing{
public void Bark();
}

Es posible ser un ser vivo sin ser un perro, pero no es posible ser un perro sin ser un ser vivo. Entonces, si puede ladrar, también puede comer, pero lo contrario no siempre es cierto.