Qual è il punto di un'interfaccia? [duplicare]

Java consente l'ereditarietà multipla dell'interfaccia; l'ereditarietà singola è per l'implementazione.

Le interfacce sono importanti perché separano ciò che una classe fa da come lo fa. Il contratto che definisce cosa può aspettarsi un cliente lascia lo sviluppatore libero di implementarlo in qualsiasi modo scelga, purché mantengano il contratto.

Vedi esempi di tutto questo su JDK. Guarda il pacchetto java.sql - è pieno di interfacce. Perché? Così diversi database relazionali possono essere liberi di implementare questi metodi per il loro particolare prodotto. I clienti devono solo gestire i tipi di riferimento dell'interfaccia. Cambiare i database relazionali è facile come scambiare un JAR del driver JDBC con un altro. I clienti non devono cambiare. (Fintanto che non si allontanano dal contratto.)

I proxy dinamici e la programmazione orientata all'aspetto dipendono dalle interfacce. Possono sostituire l'implementazione in fase di esecuzione in questo modo.

Programma contro un'interfaccia invece di un'implementazione concreta per rendere flessibile il tuo codice.

Ad esempio,

Programma contro IScrewDriver in modo che tu possa utilizzare PhilipsScrewDriver o FlatScrewDriver , in base alle tue esigenze.

Di solito, userai una sorta di contenitore IoC per "iniettare" il cacciavite appropriato sul tuo codice, ma non è davvero necessario.

Spero che gli esempi ti aiutino.

What is the point of a Java interface?

Il punto è separare l'API (cosa fare) dall'implementazione (come fare).

Le interfacce sono anche necessarie quando si usano i callback, dal momento che Java non consente il passaggio dei riferimenti alle funzioni.

Is it really Java's answer to multiple inheritance?

Tra le altre cose, sì. Ti dà alcune delle caratteristiche di MI, senza le complicazioni brutte.

Ci sono molte ragioni per cui Java ha il proprio costrutto per l'ereditarietà multipla, cioè con interface e abstract classi. Eccone tre che posso pensare:

Riduce il codice boilerplate (cioè le funzioni pure virtuali)

Nelle lingue che non hanno il costrutto interface , devi fare molta codifica di tipo standard. Considerare in C ++ è necessario creare una classe che abbia pure funzioni virtuali:

class MyInterface
{
public:
  virtual void show() = 0;
  virtual int number() = 0;
};

class ConcreteImpl : public MyInterface
{
public:
  void show()
  {
    cout << "Concrete Impl here";
  }
  int number()
  {
    return 1337;
  }
};

L'equivalente in Java sarebbe meno dettagliato, principalmente perché i metodi sono funzioni virtuali (sostituibili). Ed è più evidente che una delle risorse è l'interfaccia.

interface MyInterface {
  void show();
  int number();
}

class ConcreteImpl implements MyInterface {
   public void show() {
     System.out.println("Concrete Impl here");
   }
   public int number() { return 1337; }
}

Java consente una classe con pura virtualità mista e implementazione, con la parola chiave abstract .

Limita il problema "ereditarietà del diamante"

Uno dei problemi associati all'ereditarietà multipla è il peloso problema dell'eredità del diamante . Considera se hai un linguaggio che consente questa catena di classi in un linguaggio come C ++:

PensaaSuperBaseClasschehadueimplementatiBaseClass,entrambiimplementandoilmetododiSuperBaseClasscomefunzionivirtuali.AsuavoltaentrambiBaseClasssonoimplementatidallaclasseMyImplementation.Consideracosasuccederàsechiamisuper()inMyImplementation.draw()?Nonèsemprechiarocosasuccederà,ancheinC++,glisviluppatorichelohannoprogettatositroverannoinunastranasessionedidebug.

Nonc'ènientedisbagliatoinparticolarenell'ereditarietàdeidiamanti,quindiperevitareiproblemidichiamareilsuper-metodo,deviprogettarliusandopurefunzionivirtualiodisegnandoliinmodopiùintelligente.InJava,poichétuttiimetodisonovirtualiperimpostazionepredefinita,sièvincolatidalfattocheèpossibileeseguirel'ereditarietàmultiplasoloconinterfacespoichénoncontengonoalcunaimplementazione(conlaparolachiaveimplements).Altreclassi,ancheabstract,possonoessereereditatesolo(conlaparolachiaveextends).

Glisviluppatoristagionatiutilizzavanogiàleinterfaccecomeconcetto(circa1995)

Seseientratoin Design Patterns by GoF , noterai che fanno molto affidamento sulle interfacce per progettare sistemi estensibili. In effetti uno dei principi di Design Patterns è:

"Program to an 'interface', not an 'implementation'." (Gang of Four 1995:18)

L'interfaccia nel senso di GoF significa che dovresti programmare verso una superclasse piuttosto che l'implementazione. Un esempio potrebbe essere che dovresti preferire digitare la tua variabile su Collection<T> , Iterable<T> o List<T> anziché ArrayList<T> in Java se gli unici metodi che usi sull'oggetto lo ripetono. Un esempio di modello da GoF sarebbe il modello di strategia in cui il contesto non ha bisogno di conoscere la strategia esatta che viene data a esegui, ma eseguirà il set, indipendentemente da cosa fosse.

Questo mi confondeva fino a quando non realizzai qualcosa:

Fondamentalmente, un'interfaccia è semplicemente una classe che contiene solo metodi astratti. Rendendo tale entità in un'interfaccia ottieni una certa flessibilità che non hai con le classi.

È stato trovato questo link per essere davvero utile . Un paio di estratti che avevo senso per me:

...Separation of interface and implementation is one of the primary ideas behind Java in general. The Java virtual machine (JVM), for example, is an abstract computer that defines the way your program "interfaces" with the underlying real computer. A JVM that runs on Windows is one implementation of that abstract computer. A JVM that runs on the Macintosh is another. A JVM that runs on your wristwatch is yet another

Interfaces give you more polymorphism than singly inherited families of classes, because with interfaces you don't have to make everything fit into one family of classes.

By using interfaces, you decouple the parts of your system from each other and generate code that is more flexible: more easily changed, extended, and customized.

A implements B, C non è uguale a A extends B, C

Anche se sembra abbastanza chiaro, anch'io sono sempre stato confuso quando le persone dicono che le interfacce rispondono alla mancanza di ereditarietà multipla.

Poiché questo link mostra che esistono modi per simulare l'ereditarietà multipla mentre si usano le interfacce. Ma l'interfaccia non aiuta direttamente a implementare l'ereditarietà multipla.

L'interfaccia, credo, è per sottotipi multipli. Nell'esempio sopra, A è sia di tipo B che C. Quindi A può essere sostituito da entrambi i membri di B o membri di C (vedere questo articolo di Wikipedia ).

Dato che potresti avere più implementazioni di una singola interfaccia, aiuta anche nel polimorfismo dinamico. Il tuo codice dipende dal tipo (l'interfaccia) e non dall'implementazione (che potrebbe essere sostituita dinamicamente in base al contesto).

Sì, le interfacce sono la risposta di Java all'ereditarietà multipla. Non c'è assolutamente nulla che un'interfaccia possa fare che una classe astratta non possa fare, tranne il fatto che più interfacce possono prendere parte alla discendenza di una classe, mentre non possono farlo più classi.

Quindi, usiamo un'interfaccia invece di una classe astratta per dare ai discendenti la libertà di estendere qualsiasi classe base che desiderano (e implementare la nostra interfaccia,) piuttosto che forzarli ad estendere una classe base specifica.