Come comunicare che l'ordine di inserzione conta in una mappa?

Sto recuperando un set di tuple dal database e lo inserisco in una mappa. La query del database è costosa.

Non esiste un ordinamento naturale ovvio degli elementi nella mappa, ma l'ordine di inserimento è comunque importante. L'ordinamento della mappa sarebbe un'operazione pesante, quindi voglio evitare di farlo, dato che il risultato della query è già ordinato nel modo desiderato. Pertanto, memorizzo solo il risultato della query in a LinkedHashMape restituisco la mappa da un metodo DAO:

public LinkedHashMap<Key, Value> fetchData()

Ho un metodo processDatache dovrebbe eseguire alcune elaborazioni sulla mappa: la modifica di alcuni valori, l'aggiunta di alcune nuove chiavi / valori. È definito come

public void processData(LinkedHashMap<Key, Value> data) {...}

Tuttavia, diversi linter (sonar ecc.) Lamentano che il tipo di "dati" dovrebbe essere un'interfaccia come "Mappa" anziché l'implementazione "LinkedHashMap" ( calamaro S1319 ).
Quindi sostanzialmente sta dicendo che avrei dovuto

public void processData(Map<Key, Value> data) {...}

Ma voglio che la firma del metodo dica che l' ordine delle mappe è importante - è importante per l'algoritmo processData- in modo che il mio metodo non venga passato da qualsiasi mappa casuale.

Non voglio usarlo SortedMap, perché (dal javadoc dijava.util.SortedMap ) "è ordinato secondo l' ordinamento naturale delle sue chiavi, o da un comparatore in genere fornito al momento della creazione della mappa ordinata".

Le mie chiavi non hanno un ordinamento naturale e la creazione di un comparatore per non fare nulla sembra dettagliata.

E vorrei ancora che fosse una mappa, di cui approfittare putper evitare chiavi duplicate ecc. In caso contrario, dataavrebbe potuto essere un List<Map.Entry<Key, Value>>.

Quindi, come posso dire che il mio metodo vuole una mappa già ordinata ? Purtroppo, non esiste java.util.LinkedMapun'interfaccia, o l'avrei usata.

Quindi usa LinkedHashMap.

Sì , Mapquando possibile è necessario utilizzare un'implementazione specifica e , sì , questa è la migliore pratica.

Detto questo, questa è una situazione stranamente specifica in cui l'implementazione della Maprealtà conta. Questo non sarà vero per il 99,9% dei casi nel tuo codice quando usi Map, eppure eccoti qui, in questa situazione dello 0.1%. Il sonar non può saperlo e quindi Sonar ti dice semplicemente di evitare di utilizzare l'implementazione specifica perché sarebbe corretto nella maggior parte dei casi.

Direi che se riesci a fare un caso per usare un'implementazione specifica, non provare a mettere il rossetto su un maiale. Hai bisogno di un LinkedHashMap, non di un Map.

Detto questo, se sei nuovo nella programmazione e incappare in questa risposta, non pensare che ciò ti permetta di andare contro le migliori pratiche perché non lo è. Ma quando sostituire un'implementazione con un'altra non è accettabile, l'unica cosa che puoi fare è usare quella specifica implementazione ed essere dannato per Sonar.

Stai combattendo tre cose:

Il primo è la libreria di contenitori Java. Nulla nella sua tassonomia ti dà un modo per determinare se la classe scorre o meno in un ordine prevedibile. Non esiste IteratesInInsertedOrderMapun'interfaccia che potrebbe essere implementata da LinkedHashMap, il che rende impossibile il controllo del tipo (e l'uso di implementazioni alternative che si comportano allo stesso modo). Questo è probabilmente di progettazione, perché lo spirito è che dovresti davvero essere in grado di gestire oggetti che si comportano come l'astratto Map.

La seconda è la convinzione che ciò che dice il tuo linter debba essere trattato come un vangelo e che ignorare tutto ciò che dice è un male. Contrariamente a ciò che passa per la buona pratica in questi giorni, gli avvisi di linter non dovrebbero essere ostacoli al buon codice. Sono spunti per ragionare sul codice che hai scritto e usare la tua esperienza e giudizio per determinare se l'avviso è giustificato o meno. Avvertimenti ingiustificati sono il motivo per cui quasi tutti gli strumenti di analisi statica forniscono un meccanismo per dire che hai esaminato il codice, pensi che ciò che stai facendo sia a posto e che non dovrebbero lamentarsene in futuro.

Terzo, e questa è probabilmente la carne, LinkedHashMappotrebbe essere lo strumento sbagliato per il lavoro. Le mappe sono pensate per l'accesso casuale, non ordinato. Se processData()scorre semplicemente i record in ordine e non è necessario trovare altri record per chiave, stai forzando un'implementazione specifica di Mapfare il lavoro di a List. D'altra parte, se hai bisogno di entrambi, LinkedHashMapè lo strumento giusto perché è noto per fare quello che vuoi e sei più che giustificato nel richiederlo.

Se tutto ciò che stai ottenendo LinkedHashMapè la possibilità di sovrascrivere i duplicati, ma lo stai davvero utilizzando come un List, quindi suggerirei che è meglio comunicare tale utilizzo con la tua Listimplementazione personalizzata . Puoi basarlo su una classe di raccolte Java esistente e semplicemente ignorare qualsiasi metodo adde removeper aggiornare il tuo archivio di backup e tenere traccia della chiave per garantire l'univocità. Dare a questo un nome distintivo come ProcessingListchiarirà che gli argomenti presentati al tuo processDatametodo devono essere gestiti in un modo particolare.

Ti sento dire "Ho una parte del mio sistema che produce una LinkedHashMap e in un'altra parte del mio sistema ho bisogno di accettare solo gli oggetti LinkedHashMap prodotti dalla prima parte, poiché quelli prodotti da altri processi hanno vinto" non funziona correttamente. "

Questo mi fa pensare che il problema qui sia in realtà che stai cercando di utilizzare LinkedHashMap poiché si adatta principalmente ai dati che stai cercando, ma in realtà non può essere sostituito con nessun'altra istanza rispetto a quelle che crei. Quello che realmente vuoi fare è creare la tua interfaccia / classe che è ciò che crea la tua prima parte e la seconda parte consuma. Può racchiudere la "reale" LinkedHashMap e fornire un getter Map o implementare l'interfaccia Map.

Questo è un po 'diverso dalla risposta di CandiedOrange, in quanto consiglierei di incapsulare la vera Mappa (e delegare le chiamate ad essa secondo necessità) piuttosto che estenderla. A volte è una di quelle guerre sante di stile, ma mi sembra sicuramente che non sia "Una mappa con alcune cose aggiuntive", è "La mia valigia di utili informazioni sullo stato, che posso rappresentare internamente con una mappa".

Se avessi avuto due variabili che avresti dovuto passare in questo modo, probabilmente avresti creato una classe senza pensarci molto. Ma a volte è utile avere una classe anche se è solo una variabile membro, solo perché è logicamente la stessa cosa, non un "valore" ma "il risultato della mia operazione con cui devo fare le cose in seguito".

LinkedHashMap è l'unica mappa java che ha la funzione di ordine di inserimento che stai cercando. Quindi scartare il principio di inversione di dipendenza è allettante e forse anche pratico. Prima però, considera cosa ci vorrebbe per seguirlo. Ecco cosa ti chiederebbe SOLID .

Nota: sostituire il nome Ramdalcon un nome descrittivo che comunica che il consumatore di questa interfaccia è il proprietario di questa interfaccia. Il che lo rende l'autorità che decide se l'ordine di inserimento è importante. Se lo chiami InsertionOrderMap, hai davvero perso il punto.

public interface Ramdal {
    //ISP asks for just the methods that processData() actually uses.
    ...
}

public class RamdalLinkedHashMap extends LinkedHashMap implements Ramdal{} 

Ramdal<Key, Value> ramdal = new RamdalLinkedHashMap<>();

ramdal.put(key1, value1);
ramdal.put(key2, value2);

processData(ramdal);

È un grande design in primo piano? Forse dipende da quanto probabilmente pensi che avrai mai bisogno di un'implementazione oltre LinkedHashMap. Ma se non stai seguendo DIP solo perché sarebbe un grande dolore, non penso che la piastra della caldaia sia più dolorosa di questa. Questo è il modello che uso quando desidero che il codice intoccabile abbia implementato un'interfaccia che non ha. La parte più dolorosa è davvero pensare a buoni nomi.

Grazie per tanti buoni suggerimenti e spunti di riflessione.

Ho finito per estendere la creazione di una nuova classe di mappe, creando processDataun metodo di istanza:

class DataMap extends LinkedHashMap<Key, Value> {

   processData();

}

Quindi ho riformattato il metodo DAO in modo che non restituisca una mappa, ma invece prenda una targetmappa come parametro:

public void fetchData(Map<Key, Value> target) {
  ...
  // for each result row
  target.put(key, value);
}

Quindi popolare DataMaped elaborare i dati ora è un processo in due fasi, il che va bene, poiché ci sono alcune altre variabili che fanno parte dell'algoritmo, che proviene da altri luoghi.

public DataMap fetchDataMap() {
  var dataMap = new DataMap();
  dao.fetchData(dataMap);
  return dataMap;
}

Ciò consente alla mia implementazione di Map di controllare il modo in cui le voci vengono inserite al suo interno e nascondere i requisiti di ordinazione - ora è un dettaglio di implementazione di DataMap.

Se vuoi comunicare che la struttura di dati che hai usato è lì per un motivo, aggiungi un commento sopra la firma del metodo. Se in futuro un altro sviluppatore si imbatte in questa riga di codice e nota un avviso dello strumento, potrebbe anche notare il commento e astenersi dal "risolvere" il problema. Se non ci sono commenti, nulla impedisce loro di modificare la firma.

Sopprimere gli avvisi è inferiore a commentare secondo me, perché la soppressione stessa non indica il motivo per cui l'avvertimento è stato soppresso. Anche una combinazione di soppressione degli avvertimenti e commenti andrà bene.

Quindi, lasciami provare a capire il tuo contesto qui:

... l'ordine di inserimento è importante ... L'ordinamento della mappa sarebbe un'operazione pesante ...

... il risultato della query è già ordinato nel modo desiderato

Ora, quello che stai già facendo:

Sto recuperando un set di tuple dal database e lo inserisco in una mappa ...

Ed ecco il tuo codice attuale:

public void processData(LinkedHashMap<Key, Value> data) {...}

Il mio consiglio è di fare quanto segue:

• Usa l' iniezione delle dipendenze e inietta un po 'di MyTupleRepository nel metodo di elaborazione (MyTupleRepository è un'interfaccia implementata da oggetti che recuperano i tuoi oggetti tuple, generalmente dal DB);
• internamente al metodo di elaborazione, inserire i dati dal repository (aka DB, che già restituisce i dati ordinati) nella raccolta LinkedHashMap specifica, poiché si tratta di dettagli interni dell'algoritmo di elaborazione (perché dipende da come sono disposti i dati nella struttura dei dati );
• Nota che questo è praticamente ciò che stai già facendo, ma in questo caso ciò avverrebbe nel metodo di elaborazione. Il tuo repository è istanziato da qualche altra parte (hai già una classe che restituisce dati, questo è il repository in questo esempio)

Esempio di codice

public interface MyTupleRepository {
    Collection<MyTuple> GetAll();
}

//Concrete implementation of data access object, that retrieves 
//your tuples from DB; this data is already ordered by the query
public class DbMyTupleRepository implements MyTupleRepository { }

//Injects some abstraction of repository into the processing method,
//but make it clear that some exception might be thrown if data is not
//arranged in some specific way you need
public void processData(MyTupleRepository tupleRepo) throws DataNotOrderedException {

    LinkedHashMap<Key, Value> data = new LinkedHashMap<Key, Value>();

    //Represents the query to DB, that already returns ordered data
    Collection<MyTuple> myTuples = tupleRepo.GetAll();

    //Optional: this would throw some exception if data is not ordered 
    Validate(myTuples);

    for (MyTupleData t : myTuples) {
        data.put(t.key, t.value);
    }

    //Perform the processing using LinkedHashMap...
    ...
}

Immagino che questo eliminerebbe l'avviso Sonar e specifichi anche nel layout specifico della firma dei dati richiesti dal metodo di elaborazione.

Questa domanda è in realtà una serie di problemi con il modello di dati raggruppati in uno. Devi iniziare a districarli, uno alla volta. Soluzioni più naturali e intuitive cadranno mentre provi a semplificare ogni pezzo del puzzle.

Problema 1: non è possibile dipendere dall'ordine DB

Le descrizioni dell'ordinamento dei dati non sono chiare.

• Il potenziale problema più grande è che non stai specificando un ordinamento esplicito nel tuo database, tramite una ORDER BYclausola. Se non lo sei perché sembra troppo costoso, il tuo programma ha un bug . I database possono restituire risultati in qualsiasi ordine se non ne specifichi uno; non puoi dipendere dal fatto che i dati vengano restituiti casualmente nell'ordine solo perché hai eseguito la query più volte e sembra così. L'ordine potrebbe cambiare perché le righe vengono riorganizzate sul disco o alcune vengono eliminate e ne vengono sostituite di nuove o viene aggiunto un indice. È necessario specificare una ORDER BYclausola di qualche tipo. La velocità è inutile senza correttezza.
• Inoltre, non è chiaro cosa si intende per ordine di inserzione importante. Se si parla del database stesso, è necessario disporre di una colonna che effettivamente tiene traccia di questo, e deve essere incluso nella ORDER BYclausola. Altrimenti, hai dei bug. Se tale colonna non esiste ancora, è necessario aggiungerne una. Le opzioni tipiche per colonne come questa sarebbero una colonna data / ora di inserimento o una chiave auto-incrementante. La chiave auto-incrementante è più affidabile.

Problema 2: rendere efficiente l'ordinamento in memoria

Una volta che hai la certezza che è garantito per essere la restituzione di dati nell'ordine che ci si aspetta, è possibile sfruttare questo fatto per fare in memoria comando ordina molto più efficiente. Basta aggiungere una colonna row_number()odense_rank() (o equivalente del database) al set di risultati della query. Ora ogni riga ha un indice che ti darà un'indicazione diretta di ciò che dovrebbe essere l'ordine, e puoi ordinarlo banalmente in memoria. Assicurati solo di dare all'indice un nome significativo (come sortedBySomethingIndex).

Viola. Ora non è più necessario dipendere dall'ordine del set di risultati del database.

Problema 3: hai anche bisogno di eseguire questa elaborazione nel codice?

SQL è in realtà molto potente. È un fantastico linguaggio dichiarativo che ti consente di fare molte trasformazioni e aggregazioni sui tuoi dati. Oggigiorno la maggior parte dei DB supporta anche operazioni a file incrociate. Si chiamano funzioni finestra o analitiche:

• Funzioni della finestra PostgreSQL
• OVERClausola SQL Server per le funzioni della finestra
• Oracle Analytic Functions
• Funzioni della finestra di MySQL

Hai anche bisogno di mettere i tuoi dati in memoria in questo modo? O potresti fare tutto il lavoro nella query SQL usando le funzioni della finestra? Se riesci a fare tutto (o forse anche solo una parte significativa) del lavoro nel DB, fantastico! Il tuo problema con il codice scompare (o diventa molto più semplice)!

Problema 4: stai facendo cosa data?

Supponendo che non puoi fare tutto nel DB, fammi capire bene. Stai prendendo i dati come mappa (che è chiave per cose che non vuoi ordinare), quindi stai iterando su di esso in ordine di inserimento , e modificando la mappa in atto sostituendo il valore di alcune chiavi e aggiungendo nuovi?

Mi dispiace, ma che diamine?

I chiamanti non dovrebbero preoccuparsi di tutto questo . Il sistema che hai creato è estremamente fragile. Ci vuole solo un errore stupido (forse anche fatto da te, come abbiamo fatto tutti) per fare un piccolo cambiamento sbagliato e il tutto collassa come un mazzo di carte.

Ecco forse un'idea migliore:

• Chiedi alla tua funzione di accettare a List.
• Esistono un paio di modi in cui è possibile gestire il problema di ordinazione.
  1. Applica Fail Fast. Generare un errore se l'elenco non è nell'ordine richiesto dalla funzione. (Nota: è possibile utilizzare l'indice di ordinamento dal Problema 2 per sapere se lo è.)
  2. Crea tu stesso una copia ordinata (usando nuovamente l'indice dal problema 2).
  3. Scopri un modo per costruire la mappa stessa in ordine.
• Costruisci la mappa di cui hai bisogno internamente alla funzione, in modo che il chiamante non debba preoccuparsene.
• Ora ripeti tutto ciò che hai in ordine di rappresentazione e fai quello che devi fare.
• Restituisci la mappa o trasformala in un valore di ritorno appropriato

Una possibile variazione potrebbe essere quella di costruire una rappresentazione ordinata e quindi creare una mappa della chiave da indicizzare . Ciò ti consentirebbe di modificare la copia ordinata in atto, senza creare accidentalmente duplicati.

O forse questo ha più senso: sbarazzarsi del dataparametro e far processDataeffettivamente recuperare i propri dati. Puoi quindi documentare che lo stai facendo perché ha requisiti molto specifici sul modo in cui i dati vengono recuperati. In altre parole, rendere la funzione proprietaria dell'intero processo, non solo di un suo pezzo; le interdipendenze sono troppo forti per dividere la logica in blocchi più piccoli. (Cambia il nome della funzione nel processo.)

Forse questi non funzioneranno per la tua situazione. Non lo so senza tutti i dettagli del problema. Ma conosco un design fragile e confuso quando ne sento uno.

Sommario

Penso che il problema qui sia in definitiva che il diavolo sta nei dettagli. Quando inizio a incorrere in problemi come questo, di solito è perché ho una rappresentazione inappropriata dei miei dati per il problema che sto cercando di risolvere effettivamente. La soluzione migliore è trovare una rappresentazione migliore , e quindi il mio problema diventa semplice (forse non facile, ma diretto) da risolvere.

Trova qualcuno che capisca questo punto: il tuo compito è ridurre il tuo problema a un insieme di semplici e chiari. Quindi puoi creare un codice robusto e intuitivo. Parla con loro. Un buon codice e un buon design ti fanno pensare che qualsiasi idiota avrebbe potuto pensarli, perché sono semplici e diretti. Forse c'è uno sviluppatore senior che ha quella mentalità con cui puoi parlare.