Default vs Impl durante l'implementazione di interfacce in Java

Dopo la lettura I nomi dei pacchetti devono essere singolari o plurali? mi è venuto in mente che non ho mai visto un dibattito adeguato su uno dei miei animali domestici: denominare le implementazioni delle interfacce.

Supponiamo che tu abbia un'interfaccia Orderche deve essere implementata in vari modi, ma c'è solo l'implementazione iniziale al momento della creazione del progetto. Non si va per DefaultOrdero OrderImplo qualche altra variante per evitare la falsa dicotomia? E cosa fai quando arrivano più implementazioni?

E soprattutto ... perché?

I nomi hanno l'opportunità di trasmettere significato. Perché perdere questa opportunità con Impl?

Prima di tutto, se avrai sempre una sola implementazione, elimina l'interfaccia. Crea questo problema di denominazione e non aggiunge nulla. Ancora peggio, potrebbe causare problemi con firme del metodo incoerenti nelle API se tu e tutti gli altri sviluppatori non state attenti a usare sempre solo l'interfaccia.

Detto questo, possiamo supporre che ogni interfaccia abbia o possa avere due o più implementazioni.

• Se ne hai solo uno in questo momento e non sai in che modo l'altro potrebbe essere diverso, Default è un buon inizio.

• Se ne hai due in questo momento, nominali ciascuno secondo il suo scopo.

  Esempio: recentemente abbiamo avuto un contesto di classe concreto (in riferimento a un database). Ci siamo resi conto che dovevamo essere in grado di rappresentare un contesto offline, quindi il nome Context è stato usato per una nuova interfaccia (per mantenere la compatibilità con le vecchie API) e una nuova implementazione è stata creata, OfflineContext . Ma indovina come è stato rinominato l'originale? Esatto, ContextImpl (yikes).

  In questo caso, DefaultContext sarebbe probabilmente ok e la gente lo otterrebbe, ma non è così descrittivo come potrebbe essere. Dopo tutto, se non è offline , che cos'è? Quindi siamo andati con: OnlineContext .

Caso speciale: utilizzo del prefisso "I" sulle interfacce

Una delle altre risposte ha suggerito di utilizzare il prefisso I sulle interfacce. Preferibilmente, non è necessario farlo.

Tuttavia, se hai bisogno sia di un'interfaccia, per implementazioni personalizzate, ma hai anche un'implementazione concreta primaria che verrà utilizzata spesso e il nome di base è troppo semplice per rinunciare a un'interfaccia da solo, quindi puoi considerare di aggiungere "Io" all'interfaccia (tuttavia, va benissimo se non si adatta perfettamente a te e al tuo team).

Esempio: molti oggetti possono essere un "EventDispatcher". Per motivi di API, questo deve essere conforme a un'interfaccia. Tuttavia, si desidera anche fornire un dispatcher di eventi di base per la delega. DefaultEventDispatcher andrebbe bene, ma è un po 'lungo e se ne vedrai spesso il nome, potresti preferire utilizzare il nome base EventDispatcher per la classe concreta e implementare IEventDispatcher per implementazioni personalizzate:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Decido la denominazione in base al caso d'uso dell'interfaccia.

Se l'interfaccia viene utilizzata per il disaccoppiamento , allora scelgo Implper le implementazioni.

Se lo scopo dell'interfaccia è l' astrazione comportamentale , le implementazioni vengono denominate in base a ciò che stanno concretamente facendo. Aggiungo spesso il nome dell'interfaccia a quello. Quindi, se l'interfaccia viene chiamata Validator, io uso FooValidator.

Trovo che Defaultsia una pessima scelta. Innanzitutto inquina le funzionalità di completamento del codice, poiché i nomi iniziano sempre con esso. L'altra cosa è che un valore predefinito è soggetto a modifiche nel tempo. Quindi ciò che prima potrebbe essere un valore predefinito può qualche tempo dopo essere una funzionalità obsoleta. Quindi o inizi sempre a rinominare le tue classi non appena le impostazioni predefinite cambiano o vivi con nomi fuorvianti.

Sono d'accordo con la risposta di Nicole (in particolare che l'interfaccia probabilmente non è necessario nella maggior parte dei casi), ma per il bene della discussione mi butto fuori un ulteriore alternativa diversa OrderImple DefaultOrder: nascondere l'implementazione dietro un metodo factory statico come Orders.create(). Per esempio:

public final class Orders {
  public static Order create() {
    return new Order() {
      // Implementation goes here.
    };
  }
}

Con questo approccio, l'implementazione potrebbe essere una classe interna anonima, oppure potrebbe essere una classe privata con Defaulto Implnel nome, oppure potrebbe essere nominata in modo completamente diverso. Qualunque sia la scelta fatta, il chiamante non ha bisogno di cure, quindi avrai più flessibilità ora e in seguito quando / se decidi di cambiarlo.

Alcuni ottimi esempi di questo modello in pratica sono le classi di utilità java.util.Collectionse java.util.concurrent.Executors, i cui metodi restituiscono implementazioni nascoste. Come cita efficace Java (nell'articolo 1), questo modello può aiutare a ridurre il "Peso concettuale" dell'API.

Vado sempre OrderImplsemplicemente perché si presenta in ordine alfabetico subito dopo l' Orderinterfaccia.

Puoi nominare l'interfaccia con il prefisso I (IWhatever) e quindi implementare qualunque cosa.

Le convenzioni ufficiali sul codice Java non parlano di questo tipo di denominazione per le interfacce, tuttavia questo tipo di denominazione aiuta il riconoscimento e la navigazione.

Penso che mentre Default può avere senso in alcuni casi, sarebbe più utile descrivere l'implementazione. Quindi, se l'interfaccia è UserProfileDAOallora la vostra implementazioni possono essere UserProfileSQLDAOo UserProfileLDAPDAOo qualcosa del genere.

se possibile, chiamalo dopo cosa / come fa la sua cosa.

di solito l'approccio peggiore è chiamarlo come deve essere usato.

Se si suppone che venga utilizzato come classe base per l'implementazione, è possibile utilizzare BaseX o AbstractX (se è astratto (ma provare a fare lo squeze in quello che fa, perché se non facesse nulla non lo avresti creato, lo hai già interfaccia) Se fornisce la funzionalità più semplice possibile e si prevede che venga utilizzato direttamente (non estendendolo) quando tale funzionalità è sufficiente, è possibile chiamarlo SimpleX o BasicX.

Se viene utilizzato a meno che non venga fornita un'altra implementazione, denominarlo DefaultX

La maggior parte di queste risposte descrive ciò che viene fatto, ma non il perché.

Che cosa è successo ai principi OO? Cosa mi dice Impl di una lezione e come usarla? Dovresti preoccuparti di comprendere gli usi e non il modo in cui è costruito.

Se creo un'interfaccia Person, che cos'è un PersonImpl? Senza senso. Almeno DefaultPerson mi dice che chiunque lo abbia codificato non avrebbe dovuto creare un'interfaccia.

Le interfacce stanno digitando per il polimorfismo e dovrebbero essere usate come tali.