interfacce

Un’interfaccia è un contratto : la persona che scrive l’interfaccia dice ” hey, accetto le cose in questo modo “, e la persona che usa l’interfaccia dice ” OK, la class che scrivo sembra così “.

Un’interfaccia è una shell vuota . Ci sono solo le firme dei metodi, il che implica che i metodi non hanno un corpo. L’interfaccia non può fare nulla. È solo uno schema.

Ad esempio (pseudo codice):

// I say all motor vehicles should look like this: interface MotorVehicle { void run(); int getFuel(); } // My team mate complies and writes vehicle looking that way class Car implements MotorVehicle { int fuel; void run() { print("Wrroooooooom"); } int getFuel() { return this.fuel; } } 

L’implementazione di un’interfaccia consuma pochissima CPU, perché non è una class, solo un mucchio di nomi, e quindi non ci sono costose ricerche da fare. È fantastico quando è importante, come nei dispositivi embedded.

Lezioni astratte

Le classi astratte, a differenza delle interfacce, sono classi. Sono più costosi da usare, perché c’è una ricerca da fare quando si eredita da loro.

Le classi astratte assomigliano molto alle interfacce, ma hanno qualcosa in più: puoi definire un comportamento per loro. È più che altro una persona che dice “queste classi dovrebbero assomigliare a questo, e hanno questo in comune, quindi riempire gli spazi vuoti!”.

Per esempio:

 // I say all motor vehicles should look like this: abstract class MotorVehicle { int fuel; // They ALL have fuel, so lets implement this for everybody. int getFuel() { return this.fuel; } // That can be very different, force them to provide their // own implementation. abstract void run(); } // My teammate complies and writes vehicle looking that way class Car extends MotorVehicle { void run() { print("Wrroooooooom"); } } 

Implementazione

Mentre le classi e le interfacce astratte dovrebbero essere concetti diversi, le implementazioni rendono questa affermazione a volte non vera. A volte, non sono nemmeno ciò che pensi di essere.

In Java, questa regola è fortemente applicata, mentre in PHP, le interfacce sono classi astratte senza alcun metodo dichiarato.

In Python, le classi astratte sono più un trucco di programmazione che puoi ottenere dal modulo ABC e in realtà utilizzano metaclassi e quindi classi. E le interfacce sono più legate alla digitazione anatra in questa lingua ed è un misto tra convenzioni e metodi speciali che chiamano i descrittori (i metodi __method__).

Come al solito con la programmazione, c’è teoria, pratica e pratica in un’altra lingua 🙂

Le principali differenze tecniche tra una class astratta e un’interfaccia sono:

• Le classi astratte possono avere costanti, membri, metodi stub (metodi senza corpo) e metodi definiti , mentre le interfacce possono avere solo costanti e stub di metodi .

• Metodi e membri di una class astratta possono essere definiti con qualsiasi visibilità , mentre tutti i metodi di un’interfaccia devono essere definiti come public (sono definiti pubblici per impostazione predefinita).

• Quando si eredita una class astratta, una class figlio concreta deve definire i metodi astratti , mentre una class astratta può estendere un’altra class astratta e i metodi astratti dalla class genitore non devono essere definiti.

• Allo stesso modo, un’interfaccia che estende un’altra interfaccia non è responsabile dell’implementazione dei metodi dall’interfaccia genitore. Questo perché le interfacce non possono definire alcuna implementazione.

• Una class figlio può estendere solo una singola class (astratta o concreta), mentre un’interfaccia può estendersi o una class può implementare più altre interfacce .

• Una class figlio può definire metodi astratti con visibilità uguale o meno restrittiva , mentre una class che implementa un’interfaccia deve definire i metodi con la stessa visibilità (pubblica) esatta.

Un’interfaccia contiene solo la definizione / firma della funzionalità, e se abbiamo alcune funzionalità comuni e firme comuni, allora dobbiamo usare una class astratta. Usando una class astratta, possiamo fornire sia il comportamento che la funzionalità nello stesso tempo. Un altro sviluppatore che eredita una class astratta può utilizzare facilmente questa funzionalità, in quanto è necessario solo riempire gli spazi vuoti.

Preso da:

http://www.dotnetbull.com/2011/11/difference-between-abstract-class-and.html

http://www.dotnetbull.com/2011/11/what-is-abstract-class-in-c-net.html http://www.dotnetbull.com/2011/11/what-is-interface-in -c-net.html

Una spiegazione può essere trovata qui: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter-Pattern.htm

Una class astratta è una class che è solo parzialmente implementata dal programmatore. Può contenere uno o più metodi astratti. Un metodo astratto è semplicemente una definizione di funzione che serve a dire al programmatore che il metodo deve essere implementato in una class figlia.

Un’interfaccia è simile a una class astratta; infatti le interfacce occupano lo stesso spazio dei nomi delle classi e delle classi astratte. Per questo motivo, non è ansible definire un’interfaccia con lo stesso nome di una class. Un’interfaccia è una class completamente astratta; nessuno dei suoi metodi è implementato e invece di una sottoclass di class da esso, si dice che implementa quell’interfaccia.

Comunque trovo questa spiegazione delle interfacce un po ‘confusa. Una definizione più comune è: un’interfaccia definisce un contratto che le classi di implementazione devono soddisfare. Una definizione di interfaccia consiste in firme di membri pubblici, senza alcun codice di implementazione.

Alcune importanti differenze:

Sotto forma di tabella:

Come affermato da Joe da javapapers :

1. La differenza principale è che i metodi di un’interfaccia Java sono implicitamente astratti e non possono avere implementazioni. Una class astratta Java può avere metodi di istanza che implementano un comportamento predefinito.

2. Le variabili dichiarate in un’interfaccia Java sono per default definitive. Una class astratta può contenere variabili non finali.

3. I membri di un’interfaccia Java sono pubblici per impostazione predefinita. Una class astratta Java può avere i soliti sapori dei membri della class come privati, protetti, ecc.

4. L’interfaccia Java deve essere implementata usando la parola chiave “implements”; Una class astratta Java dovrebbe essere estesa usando la parola chiave “extends”.

5.Un’interfaccia può estendere solo un’altra interfaccia Java, una class astratta può estendere un’altra class Java e implementare più interfacce Java.

6. Una class Java può implementare più interfacce ma può estendere solo una class astratta.

7. L’interfaccia è assolutamente astratta e non può essere istanziata; Anche una class astratta Java non può essere istanziata, ma può essere invocata se esiste un main ().

8. In confronto con le classi astratte java, le interfacce java sono lente in quanto richiede un’ulteriore indiretta.

Non voglio evidenziare le differenze, che sono già state dette in molte risposte (riguardo i modificatori finali statici pubblici per le variabili nell’interfaccia e il supporto per metodi privati ​​protetti in classi astratte)

In termini semplici, vorrei dire:

interfaccia: per implementare un contratto con più oggetti non correlati

class astratta: per implementare lo stesso comportamento o un comportamento diverso tra più oggetti correlati

Dalla documentazione Oracle

Prendi in considerazione l’utilizzo di classi astratte se:

1. Vuoi condividere il codice tra diverse classi strettamente correlate.
2. Ti aspetti che le classi che estendono la tua class astratta abbiano molti metodi o campi comuni o richiedano modificatori di accesso diversi da quelli pubblici (come protetti e privati).
3. Si desidera dichiarare campi non statici o non finali.

Prendi in considerazione l’utilizzo di interfacce se:

1. Ti aspetti che le classi non correlate implementino la tua interfaccia. Ad esempio, molti oggetti non collegati possono implementare un’interfaccia Serializable .
2. Si desidera specificare il comportamento di un particolare tipo di dati, ma non si preoccupa di chi implementa il suo comportamento.
3. Vuoi sfruttare l’ereditarietà multipla del tipo.

la class astratta stabilisce “è un” rapporto con classi concrete. l’interfaccia fornisce “ha una” capacità per le classi.

Se stai cercando Java come linguaggio di programmazione, ecco alcuni altri aggiornamenti:

Java 8 ha ridotto il divario tra l’ interface e le classi abstract in una certa misura fornendo una funzione di metodo default . Un’interfaccia non ha un’implementazione per un metodo non è più valida ora.

Fare riferimento a questa pagina di documentazione per ulteriori dettagli.

Dai un’occhiata a questa domanda SE per esempi di codice per capire meglio.

Come dovrei aver spiegato la differenza tra un’interfaccia e una class astratta?

Il punto principale è che:

• L’astratto è orientato agli oggetti . Offre i dati di base che un ‘object’ dovrebbe avere e / o funzioni che dovrebbe essere in grado di fare. Riguarda le caratteristiche di base dell’object: cosa ha e cosa può fare. Quindi gli oggetti che ereditano dalla stessa class astratta condividono le caratteristiche di base (generalizzazione).
• L’interfaccia è orientata alla funzionalità . Definisce le funzionalità che un object dovrebbe avere. Indipendentemente da quale object sia, finché può fare queste funzionalità, che sono definite nell’interfaccia, va bene. Ignora tutto il resto. Un object / class può contenere diverse (gruppi di) funzionalità; quindi è ansible per una class implementare più interfacce.

Sto costruendo un edificio di 300 piani

L’ interfaccia del progetto dell’edificio

• Ad esempio, Servlet (I)

Edificio costruito fino a 200 piani – parzialmente completato — astratto

• Implementazione parziale, ad esempio servlet generico e HTTP

Costruzione completata – calcestruzzo

• Implementazione completa, ad esempio, proprio servlet

Interfaccia

• Non sappiamo nulla di implementazione, solo requisiti. Possiamo andare per un’interfaccia.
• Ogni metodo è pubblico e astratto per impostazione predefinita
• È una class astratta pura al 100%
• Se dichiariamo pubblico, non possiamo dichiararlo privato e protetto
• Se dichiariamo astratto, non possiamo dichiarare definitivo, statico, sincronizzato, strictfp e nativo
• Ogni interfaccia ha pubblico, statico e finale
• La serializzazione e il transitorio non sono applicabili, perché non possiamo creare un’istanza per l’interfaccia
• Non volatile perché è definitivo
• Ogni variabile è statica
• Quando dichiariamo una variabile all’interno di un’interfaccia, dobbiamo inizializzare le variabili durante la dichiarazione
• Istanza e blocco statico non consentiti

Astratto

• Implementazione parziale
• Ha un metodo astratto. Un’aggiunta, usa il cemento
• Nessuna limitazione per i modificatori del metodo di class astratti
• Nessuna restrizione per i modificatori di variabili di class astratte
• Non possiamo dichiarare altri modificatori se non astratti
• Nessuna limitazione per inizializzare le variabili

Tratto dal sito DurgaJobs

Quando si desidera fornire un comportamento polimorfico in una gerarchia di ereditarietà, utilizzare le classi astratte.

Quando si desidera un comportamento polimorfico per classi completamente indipendenti, utilizzare un’interfaccia.

Lavoriamo ancora su questa domanda:

La prima cosa da dirti è che 1/1 e 1 * 1 hanno lo stesso risultato, ma ciò non significa che la moltiplicazione e la divisione siano uguali. Ovviamente, mantengono un buon rapporto, ma badate entrambi sono diversi.

Sottolineerò le principali differenze e il resto è già stato spiegato:

Le classi astratte sono utili per modellare una gerarchia di classi. A prima vista, qualsiasi requisito è parzialmente chiaro su cosa esattamente deve essere costruito, ma sappiamo cosa build. E così le tue classi astratte sono le tue classi base.

Le interfacce sono utili per consentire ad altre gerarchie o classi di sapere che cosa sono capace di fare. E quando dici che sono capace di qualcosa, devi avere quella capacità. Le interfacce lo contrassegneranno come obbligatorio per una class per implementare le stesse funzionalità.

In realtà è piuttosto semplice.

Puoi pensare ad un’interfaccia come una class alla quale è permesso solo avere metodi astratti e nient’altro.

Quindi un’interfaccia può solo “dichiarare” e non definire il comportamento che la class deve avere.

Una class astratta consente di dichiarare entrambi (utilizzando metodi astratti) e definire (utilizzando le implementazioni del metodo completo) il comportamento che si desidera che la class abbia.

E una class regolare ti consente solo di definire, non dichiarare, il comportamento / le azioni che vuoi che la class abbia.

Un’ultima cosa,

In Java, è ansible implementare più interfacce, ma è ansible estenderne solo una (Classe astratta o Classe) …

Ciò significa che l’ereditarietà del comportamento definito è limitata a consentire solo uno per class … cioè se si desidera una class che incapsula il comportamento delle Classi A, B e C, si dovrebbe fare quanto segue: Classe A estende B, Classe C estende A .. è un po ‘un modo per avere ereditarietà multiple …

Interfacce d’altra parte, si potrebbe semplicemente fare: interfaccia C implementa A, B

Quindi, in effetti, Java supporta l’ereditarietà multipla solo in “comportamento dichiarato”, cioè interfacce e solo ereditarietà con comportamento definito .. a meno che non si faccia il giro del modo in cui ho descritto …

Spero che abbia senso.

L’unica differenza è che si può partecipare a eredità multiple e altre no.

La definizione di un’interfaccia è cambiata nel tempo. Pensi che un’interfaccia abbia solo dichiarazioni di metodo e siano solo contratti? Per quanto riguarda le variabili finali statiche e le definizioni predefinite dopo Java 8?

Le interfacce sono state introdotte in Java a causa del problema dei diamanti con ereditarietà multipla e questo è ciò che effettivamente intendono fare.

Le interfacce sono i costrutti creati per superare il problema dell’ereditarietà multipla e possono avere metodi astratti, definizioni predefinite e variabili finali statiche.

Vedi Perché Java consente le variabili finali statiche nelle interfacce quando sono intese solo come contratti? .

Il confronto tra l’interfaccia e la class astratta è sbagliato. Dovrebbero esserci invece altri due confronti: 1) interfaccia vs class e 2) astratta contro class finale .

Interfaccia vs class

Interface è un contratto tra due oggetti. Ad esempio, sono un postino e tu sei un pacco da consegnare. Mi aspetto che tu conosca il tuo indirizzo di consegna. Quando qualcuno mi consegna un pacchetto, deve conoscere il suo indirizzo di consegna:

 interface Package { String address(); } 

La class è un gruppo di oggetti che obbediscono al contratto. Ad esempio, sono una scatola del gruppo “Box” e obbedisco al contratto richiesto dal Postino. Allo stesso tempo obbedisco ad altri contratti:

 class Box implements Package, Property { @Override String address() { return "5th Street, New York, NY"; } @Override Human owner() { // this method is part of another contract } } 

Astratto vs Finale

La class astratta è un gruppo di oggetti incompleti. Non possono essere usati, perché mancano alcune parti. Ad esempio, sono una casella astratta di rilevamento GPS: so come controllare la mia posizione sulla mappa:

 abstract class GpsBox implements Package { @Override public abstract String address(); protected Coordinates whereAmI() { // connect to GPS and return my current position } } 

Questa class, se ereditata / estesa da un’altra class, può essere molto utile. Ma da solo – è inutile, dal momento che non può avere oggetti. Le classi astratte possono build elementi di classi finali.

La class finale è un gruppo di oggetti completi, che possono essere utilizzati, ma non possono essere modificati. Sanno esattamente come lavorare e cosa fare. Ad esempio, sono un Box che va sempre all’indirizzo specificato durante la sua costruzione:

 final class DirectBox implements Package { private final String to; public DirectBox(String addr) { this.to = addr; } @Override public String address() { return this.to; } } 

Nella maggior parte delle lingue, come Java o C ++, è ansible avere solo una class , né astratta né definitiva. Una tale class può essere ereditata e può essere istanziata. Non penso che questo sia strettamente in linea con il paradigma orientato agli oggetti, però.

Ancora una volta, il confronto delle interfacce con le classi astratte non è corretto.

In breve le differenze sono le seguenti:

Differenze sintattiche tra interfaccia e class astratta :

1. Metodi e membri di una class astratta possono avere visibilità. Tutti i metodi di un’interfaccia devono essere pubblici . // Non è più valido da Java 9
2. Una class di bambini concreti di una class astratta deve definire tutti i metodi astratti. Una class bambino astratta può avere metodi astratti. Un’interfaccia che estende un’altra interfaccia non deve fornire un’implementazione predefinita per i metodi ereditati dall’interfaccia genitore.
3. Una class figlio può estendere solo una singola class. Un’interfaccia può estendere più interfacce. Una class può implementare più interfacce.
4. Una class figlio può definire metodi astratti con visibilità uguale o meno restrittiva, mentre la class che implementa un’interfaccia deve definire pubblici tutti i metodi dell’interfaccia.
5. Le classi astratte possono avere costruttori ma non interfacce .
6. Le interfacce di Java 9 hanno metodi statici privati.

In Interfaces ora:

public static – supportato
public abstract – supportato
public default – supportato
private static – supportato
private abstract – errore di compilazione
private default – errore di compilazione
private – supportato

Interfaccia: gira (gira a sinistra, gira a destra.)

Classe astratta: ruota.

Classe: il volante, deriva dalla ruota, espone il giro dell’interfaccia

Uno è per categorizzare il comportamento che può essere offerto attraverso una vasta gamma di cose, l’altro è per modellare un’ontologia delle cose.

Non è davvero la risposta alla domanda originale, ma una volta che hai la risposta alla differenza tra loro, entrerai nel dilemma di quando-per-utilizzare: quando utilizzare le interfacce o le classi astratte? Quando usare entrambi?

Ho una conoscenza limitata di OOP, ma vedere le interfacce come un equivalente di un aggettivo in grammatica ha funzionato per me fino ad ora (correggimi se questo metodo è falso!). Ad esempio, i nomi delle interfacce sono come attributi o capacità che puoi dare a una class, e una class può avere molti di essi: ISerializable, ICountable, IList, ICacheable, IHappy, …

Se hai metodi comuni che possono essere usati da più classi, vai per le classi astratte. Altrimenti se si desidera che le classi seguano un progetto preciso per le interfacce.

Gli esempi seguenti lo dimostrano.

Classe astratta in Java:

 abstract class animals { // They all love to eat. So let's implement them for everybody void eat() { System.out.println("Eating..."); } // The make different sounds. They will provide their own implementation. abstract void sound(); } class dog extends animals { void sound() { System.out.println("Woof Woof"); } } class cat extends animals { void sound() { System.out.println("Meoww"); } } 

Di seguito è una implementazione di interfaccia in Java:

 interface Shape { void display(); double area(); } class Rectangle implements Shape { int length, width; Rectangle(int length, int width) { this.length = length; this.width = width; } @Override public void display() { System.out.println("****\n* *\n* *\n****"); } @Override public double area() { return (double)(length*width); } } class Circle implements Shape { double pi = 3.14; int radius; Circle(int radius) { this.radius = radius; } @Override public void display() { System.out.println("O"); // :P } @Override public double area() { return (double)((pi*radius*radius)/2); } } 

Alcuni punti chiave importanti in poche parole:

1. Le variabili dichiarate nell’interfaccia Java sono per default definitive. Le classi astratte possono avere variabili non definitive.

2. Le variabili dichiarate nell’interfaccia Java sono di default statiche. Le classi astratte possono avere variabili non statiche.

3. I membri di un’interfaccia Java sono pubblici per impostazione predefinita. Una class astratta Java può avere i soliti sapori dei membri della class come privati, protetti, ecc.

L’ereditarietà viene utilizzata per due scopi:

• Per consentire a un object di considerare i membri di dati di tipo principale e le implementazioni del metodo come proprie.

• Per consentire un riferimento a un object di un tipo da utilizzare con il codice che si aspetta un riferimento all’object supertipo.

Nei linguaggi / framework che supportano l’ereditarietà multipla generalizzata, spesso è poco necessario classificare un tipo come “interfaccia” o “class astratta”. I linguaggi e le strutture popolari, tuttavia, consentiranno a un tipo di considerare i membri dei dati di un altro tipo o le implementazioni del metodo come proprie, anche se consentono a un tipo di essere sostituibile per un numero arbitrario di altri tipi.

Le classi astratte possono avere membri di dati e implementazioni di metodi, ma possono essere ereditate solo da classi che non ereditano da altre classi. Le interfacce non mettono quasi nessuna restrizione sui tipi che le implementano, ma non possono includere alcun membro di dati o implementazioni di metodi.

Ci sono momentjs in cui è utile che i tipi siano sostituibili a molte cose diverse; ci sono altre volte in cui è utile che gli oggetti considerino i membri dei dati di tipo genitore e le implementazioni dei metodi come propri. Fare una distinzione tra interfacce e classi astratte consente a ciascuna di queste abilità di essere utilizzata nei casi in cui è più rilevante.

Punti chiave:

• La class astratta può avere proprietà, campi dati, metodi (completi / incompleti) entrambi.
• Se il metodo o le proprietà vengono definiti in una parola chiave astratta che deve essere sovrascritta nella class derivata. (Funziona come una funzionalità strettamente accoppiata)
• Se si definisce la parola chiave astratta per metodo o proprietà nella class astratta, non è ansible definire il corpo del metodo e il valore get / set per le proprietà e questo deve eseguire l’override nella class derivata.
• La class astratta non supporta l’ereditarietà multipla.
• La class astratta contiene costruttori.
• Una class astratta può contenere modificatori di accesso per i sottotitoli, le funzioni, le proprietà.
• Solo il Membro completo della class astratta può essere statico.
• Un’interfaccia può ereditare solo da un’altra interfaccia e non può ereditare da una class astratta, dove una class astratta può ereditare da un’altra class astratta o da un’altra interfaccia.

Vantaggio:

• È un tipo di contratto che costringe tutte le sottoclassi a portare avanti le stesse gerarchie o standard.
• Se varie implementazioni sono dello stesso tipo e usano comportamenti o stati comuni, la class astratta è meglio usarla.
• Se aggiungiamo un nuovo metodo a una class astratta, abbiamo la possibilità di fornire un’implementazione predefinita e quindi tutto il codice esistente potrebbe funzionare correttamente.
• Permette un’esecuzione rapida rispetto all’interfaccia (interfaccia richiede più tempo per trovare il metodo effettivo nelle classi corrispondenti).
• Può usare per accoppiamento stretto e senza stringere.

trova i dettagli qui … http://pradeepatkari.wordpress.com/2014/11/20/interface-and-abstract-class-in-c-oops/

Il modo più breve per riassumere è che interface è:

1. Completamente astratto, a parte static metodi default e static ; mentre ha definizioni (firme + metodi) per metodi default e static , ha solo dichiarazioni (firme del metodo) per altri metodi.
2. Sobject a regole più lassiste delle classi (una class può implementare più interface e interface può ereditare da più interface ). Tutte le variabili sono implicitamente costanti, se specificate come public static final o meno. Tutti i membri sono implicitamente public , se specificati come tali o meno.
3. Generalmente utilizzato come garanzia che la class di implementazione avrà le caratteristiche specificate e / o compatibile con qualsiasi altra class che implementa la stessa interfaccia.

Nel frattempo, una class abstract è:

1. Ovunque da completamente astratto a completamente implementato, con la tendenza ad avere uno o più metodi abstract . Può contenere sia dichiarazioni che definizioni, con dichiarazioni contrassegnate come abstract .
2. Una class a tutti gli effetti, soggetta alle regole che governano le altre classi (può ereditare solo da una class), a condizione che non possa essere istanziata (perché non si garantisce che sia completamente implementata). Può avere variabili membro non costanti. Può implementare il controllo di accesso dei membri, limitando i membri come pacchetti protected , private o privati ​​(non specificati).
3. Generalmente utilizzato per fornire la maggior parte dell’implementazione che può essere condivisa da più sottoclassi o per fornire la maggior parte dell’implementazione che il programmatore è in grado di fornire.

Or, if we want to boil it all down to a single sentence: An interface is what the implementing class has , but an abstract class is what the subclass is .

Many junior developers make the mistake of thinking of interfaces, abstract and concrete classs as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: “I” . When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.

Interfaces and abstract classs, although apparently similar from a technical point of view, have completely different meanings and purposes.

Sommario

1. An interface defines a contract that some implementation will fulfill for you .

2. An abstract class provides a default behavior that your implementation can reuse.

Alternative summary

1. An interface is for defining public APIs
2. An abstract class is for internal use, and for defining SPIs

On the importance of hiding implementation details

A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you’re going to use them. When you’re trying to squeeze performance out of a list that you’re heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you’re instantiating.

On the other hand, high level users of a list don’t really care how it is actually implemented, and they should be insulated from these details. Let’s imagine that Java didn’t expose the List interface, but only had a concrete List class that’s actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible… But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn’t be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it’s important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.

An abstract class is in the middle between interfaces and concrete classs. It is supposed to help implementations share common or boring code. For example, AbstractCollection provides basic implementations for isEmpty based on size is 0, contains as iterate and compare, addAll as repeated add , and so on. This lets implementations focus on the crucial parts that differentiate between them: how to actually store and retrieve data.

APIs versus SPIs

Interfaces are low-cohesion gateways between different parts of code. They allow libraries to exist and evolve without breaking every library user when something changes internally. It’s called Application Programming Interface , not Application Programming Classes. On a smaller scale, they also allow multiple developers to collaborate successfully on large scale projects, by separating different modules through well documented interfaces.

Abstract classs are high-cohesion helpers to be used when implementing an interface, assuming some level of implementation details. Alternatively, abstract classs are used for defining SPIs, Service Provider Interfaces.

The difference between an API and an SPI is subtle, but important: for an API, the focus is on who uses it, and for an SPI the focus is on who implements it.

Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classs are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.

A note on Java 8 and default methods

Although Java 8 introduced default methods for interfaces, which makes the line between interfaces and abstract classs even blurrier, this wasn’t so that implementations can reuse code, but to make it easier to change interfaces that serve both as an API and as an SPI (or are wrongly used for defining SPIs instead of abstract classs).

Which one to use?

1. Is the thing supposed to be publicly used by other parts of the code, or by other external code? Add an interface to it to hide the implementation details from the public abstract contract, which is the general behavior of the thing.
2. Is the thing something that’s supposed to have multiple implementations with a lot of code in common? Make both an interface and an abstract, incomplete implementation.
3. Is there ever going to be only one implementation, and nobody else will use it? Just make it a concrete class.
   1. “ever” is long time, you could play it safe and still add an interface on top of it.

A corollary: the other way around is often wrongly done: when using a thing , always try to use the most generic class/interface that you actually need. In other words, don’t declare your variables as ArrayList theList = new ArrayList() , unless you actually have a very strong dependency on it being an array list, and no other type of list would cut it for you. Use List theList = new ArrayList instead, or even Collection theCollection = new ArrayList if the fact that it’s a list, and not any other type of collection doesn’t actually matter.

By definition, interfaces cannot have an implementation for any methods, and member variables cannot be initialized.

However, abstract classs can have methods implementated and member variables initialized.

Use abstract classs when you expect changes in your contract, ie, say in future you might need to add a new method.

In this situation, if you decide to use an interface, when the interface is changed to include interface, your application will break when you dumped the new interface dll.

To read in detail, visit difference between abstract class and a interface

I’d like to add one more difference which makes sense. For example, you have a framework with thousands of lines of code. Now if you want to add a new feature throughout the code using a method enhanceUI(), then it’s better to add that method in abstract class rather in interface. Because, if you add this method in an interface then you should implement it in all the implemented class but it’s not the case if you add the method in abstract class.

Differences between abstract class and interface on behalf of real implementation.

Interface : It is a keyword and it is used to define the template or blue print of an object and it forces all the sub classs would follow the same prototype,as for as implementation, all the sub classs are free to implement the functionality as per it’s requirement.

Some of other use cases where we should use interface.

Communication between two external objects(Third party integration in our application) done through Interface here Interface works as Contract.

Abstract Class: Abstract,it is a keyword and when we use this keyword before any class then it becomes abstract class.It is mainly used when we need to define the template as well as some default functionality of an object that is followed by all the sub classs and this way it removes the redundant code and one more use cases where we can use abstract class , such as we want no other classs can directly instantiate an object of the class, only derived classs can use the functionality.

Example of Abstract Class:

  public abstract class DesireCar { //It is an abstract method that defines the prototype. public abstract void Color(); // It is a default implementation of a Wheel method as all the desire cars have the same no. of wheels. // and hence no need to define this in all the sub classs in this way it saves the code duplicasy public void Wheel() { Console.WriteLine("Car has four wheel"); } } **Here is the sub classs:** public class DesireCar1 : DesireCar { public override void Color() { Console.WriteLine("This is a red color Desire car"); } } public class DesireCar2 : DesireCar { public override void Color() { Console.WriteLine("This is a red white Desire car"); } } 

Example Of Interface:

  public interface IShape { // Defines the prototype(template) void Draw(); } // All the sub classs follow the same template but implementation can be different. public class Circle : IShape { public void Draw() { Console.WriteLine("This is a Circle"); } } public class Rectangle : IShape { public void Draw() { Console.WriteLine("This is a Rectangle"); } } 

You can find clear difference between interface and abstract class.

Interface

• Interface only contains abstract methods.
• Force users to implement all methods when implements the interface.
• Contains only final and static variables.
• Declare using interface keyword.
• All methods of an interface must be defined as public.
• An interface can extend or a class can implement multiple other interfaces.

Abstract class

• Abstract class contains abstract and non-abstract methods.

• Does not force users to implement all methods when inherited the abstract class.

• Contains all kinds of variables including primitive and non-primitive

• Declare using abstract keyword.

• Methods and members of an abstract class can be defined with any visibility.

• A child class can only extend a single class (abstract or concrete).

Here is a very basic understanding over interface vs abstract class.

An abstract class is a class whose object cannot be created or a class which cannot be instantiated. An abstract method makes a class abstract. An abstract class needs to be inherited in order to override the methods that are declared in the abstract class. No restriction on access specifiers. An abstract class can have constructor and other concrete(non abstarct methods ) methods in them but interface cannot have.

An interface is a blueprint/template of methods.(eg. A house on a paper is given(interface house) and different architects will use their ideas to build it(the classs of architects implementing the house interface) . It is a collection of abstract methods , default methods , static methods , final variables and nested classs. All members will be either final or public , protected and private access specifiers are not allowed.No object creation is allowed. A class has to be made in order to use the implementing interface and also to override the abstract method declared in the interface. An interface is a good example of loose coupling(dynamic polymorphism/dynamic binding) An interface implements polymorphism and abstraction.It tells what to do but how to do is defined by the implementing class. For Eg. There’s a car company and it wants that some features to be same for all the car it is manufacturing so for that the company would be making an interface vehicle which will have those features and different classs of car(like Maruti Suzkhi , Maruti 800) will override those features(functions).

Why interface when we already have abstract class? Java supports only multilevel and hierarchal inheritance but with the help of interface we can implement multiple inheritance.

To give a simple but clear answer, it helps to set the context : you use both when you do not want to provide full implementations.

The main difference then is an interface has no implementation at all (only methods without a body) while abstract classs can have members and methods with a body as well, ie can be partially implemented.

In an interface all methods must be only definitions, not single one should be implemented.

But in an abstract class there must an abstract method with only definition, but other methods can be also in the abstract class with implementation…

I read a simple yet effective explanation of Abstract class and Interface on php.net

Which is as follows.

An Interface is like a protocol. It doesn’t designate the behavior of the object; it designates how your code tells that object to act. An interface would be like the English Language: defining an interface defines how your code communicates with any object implementing that interface.

An interface is always an agreement or a promise. When a class says “I implement interface Y”, it is saying “I promise to have the same public methods that any object with interface Y has”.

On the other hand, an Abstract Class is like a partially built class. It is much like a document with blanks to fill in. It might be using English, but that isn’t as important as the fact that some of the document is already written.

An abstract class is the foundation for another object. When a class says “I extend abstract class Y”, it is saying “I use some methods or properties already defined in this other class named Y”.

So, consider the following PHP:

You would have your class implement a particular interface if you were distributing a class to be used by other people. The interface is an agreement to have a specific set of public methods for your class.

You would have your class extend an abstract class if you (or someone else) wrote a class that already had some methods written that you want to use in your new class.

These concepts, while easy to confuse, are specifically different and distinct. For all intents and purposes, if you’re the only user of any of your classs, you don’t need to implement interfaces.