Perché tutti i campi in un’interfaccia sono implicitamente statici e definitivi?

Sto solo cercando di capire perché tutti i campi definiti in un’interfaccia sono implicitamente static e final . L’idea di mantenere i campi static ha senso per me dato che non puoi avere oggetti di un’interfaccia, ma perché sono final (implicitamente)?

Qualcuno sa perché i progettisti Java sono andati a rendere i campi in un’interfaccia static e final ?

Un’interfaccia non può avere il comportamento o lo stato perché è destinato a specificare solo un contratto di interazione, nessun dettaglio di implementazione. Nessun comportamento viene applicato non consentendo ai corpi del metodo / costruttore o ai blocchi di inizializzazione dell’istanza / dell’istanza. Nessuno stato viene applicato consentendo solo campi finali statici. Di conseguenza, la class può avere uno stato (stato statico), ma lo stato dell’istanza non viene dedotto dall’interfaccia.

BTW: una costante in Java è definita da un campo finale statico (e per convenzione il nome utilizza UPPER_CASE_AND_UNDERSCORES).

MOTIVO PER ESSERE final

Qualsiasi implementazione può modificare il valore dei campi se non sono definiti come definitivi. Quindi diventerebbero parte dell’attuazione. Un’interfaccia è una specifica pura senza alcuna implementazione.

MOTIVO PER ESSERE static

Se sono statici, appartengono all’interfaccia e non all’object né al tipo di runtime dell’object.

Ci sono un paio di punti qui trattati:

Solo perché i campi in un’interfaccia implicitamente statica finale non significa che devono essere costanti in fase di compilazione, o addirittura immutabili. È ansible definire ad es

 interface I { String TOKEN = SomeOtherClass.heavyComputation(); JButton BAD_IDEA = new JButton("hello"); } 

(Fare attenzione a fare questo all’interno di una definizione di annotazione può confondere javac , in relazione al fatto che la precedente compilazione di un inizializzatore statico).

Inoltre, il motivo di questa restrizione è più stilistico che tecnico e molte persone vorrebbero vederlo rilassato .

I campi devono essere statici perché non possono essere astratti (come i metodi possono). Poiché non possono essere astratti, gli implementatori non saranno in grado di fornire logicamente la diversa implementazione dei campi.

I campi devono essere definitivi, penso, perché i campi possono essere accessibili da molti implementatori diversi che consentono loro di essere modificabili potrebbero essere problematici (come la sincronizzazione). Anche per evitare che venga re-implementato (nascosto).

Solo il mio pensiero

Considero il requisito che i campi siano definitivi indebitamente restrittivi e un errore da parte dei progettisti del linguaggio Java. Ci sono dei momentjs, ad esempio la gestione degli alberi, quando è necessario impostare le costanti nell’implementazione necessarie per eseguire operazioni su un object del tipo di interfaccia. La selezione di un percorso di codice nella class di implementazione è un kludge. La soluzione alternativa che utilizzo è definire una funzione di interfaccia e implementarla restituendo un valore letterale:

 public interface iMine { String __ImplementationConstant(); ... } public class AClass implements iMine { public String __ImplementationConstant(){ return "AClass value for the Implementation Constant"; } ... } public class BClass implements iMine { public String __ImplementationConstant(){ return "BClass value for the Implementation Constant"; } ... } 

Tuttavia, sarebbe più semplice, più chiaro e meno incline all’implementazione aberrante utilizzare questa syntax:

 public interface iMine { String __ImplementationConstant; ... } public class AClass implements iMine { public static String __ImplementationConstant = "AClass value for the Implementation Constant"; ... } public class BClass implements iMine { public static String __ImplementationConstant = "BClass value for the Implementation Constant"; ... } 

Specifiche, contratti … L’istruzione macchina per l’accesso al campo utilizza l’indirizzo dell’object più l’offset del campo. Poiché le classi possono implementare molte interfacce, non c’è modo di rendere il campo dell’interfaccia non finale lo stesso offset in tutte le classi che estendono questa interfaccia. Pertanto, è necessario implementare diversi meccanismi per l’accesso al campo: due accessi alla memoria (ottenga l’offset del campo, ottiene il valore del campo) invece di uno più mantenendo il tipo di tabella dei campi virtuali (analogamente alla tabella dei metodi virtuali). Immagino che non volessero complicare jvm per funzionalità che possono essere facilmente simulate tramite materiali esistenti (metodi).

In scala possiamo avere campi nelle interfacce, sebbene internamente siano implementati come ho spiegato sopra (come metodi).

static :

Qualsiasi cosa (variabile o metodo) che sia static in Java può essere invocata come Classname.variablename o Classname.methodname o direttamente. Non è obbligatorio invocarlo solo utilizzando il nome dell’object.

Nell’interfaccia, gli oggetti non possono essere dichiarati e static rende ansible invocare variabili solo attraverso il nome della class senza la necessità del nome dell’object.

final :

Aiuta a mantenere un valore costante per una variabile in quanto non può essere sovrascritta nelle sue sottoclassi.