Buone o cattive pratiche per mascherare le raccolte Java con nomi di classe significativi?

Ultimamente ho preso l'abitudine di "mascherare" le raccolte Java con nomi di classe a misura d'uomo. Alcuni semplici esempi:

// Facade class that makes code more readable and understandable.
public class WidgetCache extends Map<String, Widget> {
}

O:

// If you saw a ArrayList<ArrayList<?>> being passed around in the code, would you
// run away screaming, or would you actually understand what it is and what
// it represents?
public class Changelist extends ArrayList<ArrayList<SomePOJO>> {
}

Un collega mi ha fatto notare che si tratta di una cattiva pratica e introduce ritardo / latenza, oltre ad essere un anti-pattern OO. Posso capirlo introducendo un livello molto piccolo di prestazioni generali, ma non riesco a immaginare che sia del tutto significativo. Quindi chiedo: è buono o cattivo da fare, e perché?

Lag / latenza? Chiamo BS su questo. Dovrebbe esserci esattamente zero overhead da questa pratica. ( Modifica: è stato sottolineato nei commenti che questo può, in effetti, inibire le ottimizzazioni eseguite dalla VM HotSpot. Non conosco abbastanza sull'implementazione della VM per confermarlo o negarlo. Stavo basando il mio commento sul C ++ implementazione di funzioni virtuali.)

C'è del sovraccarico di codice. Devi creare tutti i costruttori dalla classe base che desideri, inoltrandone i parametri.

Inoltre non lo vedo come un anti-pattern, di per sé. Tuttavia, lo vedo come un'occasione mancata. Invece di creare una classe che deriva la classe di base solo per motivi di ridenominazione, che ne pensi di creare una classe che contiene la raccolta e offre un'interfaccia migliorata specifica per ogni caso? La cache dei widget dovrebbe davvero offrire l'interfaccia completa di una mappa? O dovrebbe invece offrire un'interfaccia specializzata?

Inoltre, nel caso delle raccolte, il modello semplicemente non funziona insieme alla regola generale dell'uso delle interfacce, non delle implementazioni - vale a dire, in un semplice codice di raccolta, si dovrebbe creare un HashMap<String, Widget>e quindi assegnarlo a una variabile di tipo Map<String, Widget>. Il tuo WidgetCachenon può estendere Map<String, Widget>, perché è un'interfaccia. Non può essere un'interfaccia che estende l'interfaccia di base, perché HashMap<String, Widget>non implementa quell'interfaccia, e nemmeno un'altra raccolta standard. E mentre puoi renderlo una classe che si estende HashMap<String, Widget>, devi quindi dichiarare le variabili come WidgetCacheo Map<String, Widget>, e il primo ti perde la flessibilità di sostituire una raccolta diversa (forse una raccolta di caricamento lazy di ORM), mentre il secondo tipo di sconfigge il punto di avere la classe.

Alcuni di questi contrappunti si applicano anche alla mia classe specializzata proposta.

Questi sono tutti punti da considerare. Potrebbe essere o meno la scelta giusta. In entrambi i casi, gli argomenti offerti dal collega non sono validi. Se pensa che sia un anti-schema, dovrebbe nominarlo.

Secondo IBM questo in realtà è un anti-pattern. Queste classi simili a "typedef" sono chiamate tipi psuedo.

L'articolo lo spiega molto meglio di me, ma proverò a riassumerlo nel caso in cui il link non funzioni:

• Qualsiasi codice che prevede a WidgetCachenon può gestire aMap<String, Widget>
• Questi pseudotipi sono "virali" quando si usano più pacchetti che portano a incompatibilità mentre il tipo base (solo una stupida Mappa <...>) avrebbe funzionato in tutti i casi in tutti i pacchetti.
• I pseudo tipi sono spesso concreti, non implementano interfacce specifiche perché le loro classi di base implementano solo la versione generica.

Nell'articolo propongono il seguente trucco per rendere la vita più semplice senza usare pseudo tipi:

public static <K,V> Map<K,V> newHashMap() {
    return new HashMap<K,V>(); 
}

Map<Socket, Future<String>> socketOwner = Util.newHashMap();

Che funziona a causa dell'inferenza di tipo automatica.

(Sono arrivato a questa risposta tramite questa domanda di overflow dello stack correlata)

Il colpo di prestazione sarebbe limitato al massimo a una ricerca di vtable, che molto probabilmente stai già subendo. Non è un motivo valido per opporvisi.

La situazione è abbastanza comune che la maggior parte di tutti i linguaggi di programmazione tipicamente statici hanno una sintassi speciale per i tipi di alias, generalmente chiamati a typedef. Java probabilmente non li ha copiati perché in origine non aveva tipi con parametri. L'estensione di una classe non è l'ideale, a causa dei motivi che Sebastian ha affrontato così bene nella sua risposta, ma può essere una soluzione ragionevole per la sintassi limitata di Java.

I typedef presentano numerosi vantaggi. Esprimono più chiaramente l'intenzione del programmatore, con un nome migliore, a un livello più appropriato di astrazione. Sono più facili da cercare per scopi di debug o refactoring. Considera di trovare ovunque a WidgetCachesia usato anziché trovare quegli usi specifici di a Map. Sono più facili da modificare, ad esempio se in seguito scopri di aver bisogno di un LinkedHashMapcontenitore o anche del tuo contenitore personalizzato.

Ti suggerisco, come già menzionato da altri, di usare la composizione sull'ereditarietà, in modo da poter esporre solo i metodi realmente necessari, con nomi che corrispondono al caso d'uso previsto. Gli utenti della tua classe devono davvero sapere che si WidgetCachetratta di una mappa? Ed essere in grado di farne tutto ciò che vogliono? O hanno solo bisogno di sapere che è una cache per i widget?

Classe di esempio dal mio codebase, con soluzione a un problema simile che hai descritto:

public class Translations {

    private Map<Locale, Properties> translations = new HashMap<>();

    public void appendMessage(Locale locale, String code, String message) {
        /* code */
    }

    public void addMessages(Locale locale, Properties messages) {
        /* code */
    }

    public String getMessage(Locale locale, String code) {
        /* code */
    }

    public boolean localeExists(Locale locale) {
        /* code */
    }
}

Puoi vedere che internamente è "solo una mappa", ma l'interfaccia pubblica non lo mostra. E ha metodi "a misura di programmatore" come appendMessage(Locale locale, String code, String message)per un modo più semplice e significativo di inserire nuove voci. E gli utenti di classe non possono farlo, ad esempio translations.clear(), perché Translationsnon si stanno estendendo Map.

Facoltativamente, puoi sempre delegare alcuni dei metodi necessari alla mappa utilizzata internamente.

Vedo questo come un esempio di un'astrazione significativa. Una buona astrazione ha un paio di tratti:

1. Nasconde i dettagli di implementazione che sono irrilevanti per il codice che lo consuma.

2. È tanto complesso quanto deve essere.

Estendendo, stai esponendo l'intera interfaccia del genitore, ma in molti casi potrebbe essere meglio nascosto, quindi vorrai fare ciò che Sebastian Redl suggerisce e favorire la composizione rispetto all'eredità e aggiungere un'istanza del genitore come un membro privato della tua classe personalizzata. Qualsiasi metodo di interfaccia che abbia senso per la tua astrazione può essere facilmente delegato (nel tuo caso) alla collezione interna.

Per quanto riguarda l'impatto sulle prestazioni, è sempre una buona idea ottimizzare prima il codice per la leggibilità e, se si sospetta un impatto sulle prestazioni, profilare il codice per confrontare le due implementazioni.

+1 alle altre risposte qui. Aggiungerò anche che in realtà è considerata un'ottima pratica dalla community di Domain Driven Design (DDD). Sostengono che il tuo dominio e le interazioni con esso debbano avere un significato semantico rispetto alla struttura di dati sottostante. A Map<String, Widget>potrebbe essere una cache, ma potrebbe anche essere qualcos'altro, ciò che hai fatto correttamente in My Not So Humble Opinion (IMNSHO) è modellare ciò che la raccolta rappresenta, in questo caso una cache.

Aggiungerò un'importante modifica in quanto il wrapper della classe di dominio attorno alla struttura di dati sottostante dovrebbe probabilmente avere anche altre variabili o funzioni del membro che lo rendono davvero una classe di dominio con interazioni anziché solo una struttura di dati (se solo Java avesse Tipi di valore , li avremo in Java 10 - prometto!)

Sarà interessante vedere quale impatto avranno i flussi di Java 8 su tutto questo, posso immaginare che forse alcune interfacce pubbliche preferiranno gestire un flusso di (inserire una primitiva o stringa Java comune) anziché un oggetto Java.