Classi lavabili: dovrei mantenere solo l'id per i risultati o l'intera classe

Question

Classi lavabili: dovrei mantenere solo l'id per i risultati o l'intera classe

Naviga le tue risposte

#1 da (1 voti)
#2 da (1 voti)

0

Dati 2 oggetti / classi:

Una classe per una nave da carico. Ha una piccola serie di attributi, ad esempio posizione attuale, dimensioni, numero di membri dell'equipaggio e altre cose. Più importante, ha un attributo per l'id che è unico e la classe è lavabile.
Una classe per un porto. Di nuovo una piccola lista di attributi come la posizione e l'identificatore univoco. Questa classe è anche lavabile.

Ora potresti porre domande interessanti come:

Per ogni nave da carico qual è il porto più vicino insieme alla sua distanza.
Per ogni porto forniscimi un elenco di tutte le navi da carico entro un raggio di 100 km.
Dammi per ogni nave da carico una lista di tutti i porti visitati l'anno scorso (probabilmente hai bisogno di qualche informazione in più per questa domanda, ma questo dettaglio omettiamo per ora come lo riguarda i risultati).

Quindi assumiamo che le classi siano immutabili. Tutte le classi sono anche nella memoria del computer.

Ora la mia domanda è come memorizzare i risultati di determinate domande in memoria? Dovrei, per ogni domanda, mantenere solo le relazioni tra gli id (che ogni nave da carico e porto ha) o posso mantenere intere classi che dovrebbero funzionare perché sono lavabili?

Un piccolo esempio per la domanda 2:

Quando tengo solo ID, potrebbe apparire come segue:

{5235: [735235, 25245, 954646],

3232: [112, 34345, 65354, 45454]}

O dovrebbe essere così:

{(un'intera classe di porto): [(un'intera classe di nave), (un'intera classe di nave), (un'intera classe di nave)],

(un'intera classe di porto): [(un'intera classe di nave), (un'intera classe di nave), (un'intera classe di nave), (un'intera classe di nave)]}

(Durante la stesura di questo messaggio mi è venuta in mente un'altra domanda, se l'identificatore univoco fosse un attributo della classe, voglio dire che ogni domanda che si pone non ha strettamente nulla a che fare con l'identificatore)

class-design hashing

posta Elmex80s 29.01.2018 - 00:05

fonte

2 risposte

Leggi altre domande sui tag class-design hashing

Qual è la migliore pratica per gli endpoint API per un'entità? Sviluppo di SQL - REST Adapter

score 1 · Answer 1

Should I for each question only keep the relations between the id's (which each cargo ship and harbor has) or can I keep the entire classes which should work because they are hashable?

Perché sembra che le navi si muoveranno e quindi i dati memorizzati nella mappa cambieranno di frequente, è probabilmente più efficiente per memorizzare solo i loro ID nella mappa (e memorizzare la nave / porto istanze altrove dove è possibile cercarli per ID quando necessario). Quando si memorizza un'istanza nave / porto nella mappa, i rehashes saranno più costosi poiché l'intero oggetto (potenzialmente di grandi dimensioni) dovrebbe essere copiato nella sua nuova posizione.

should the unique identifier be an attribute of the class, I mean every question you ask has strictly nothing to do with the identifier

Questo dipende dal fatto che la nave / porto abbia bisogno di conoscere il proprio ID o se sia necessario trovare un ID dato solo alla nave / porto. Se uno di questi è vero, probabilmente è più semplice memorizzare l'ID come membro della classe. In caso contrario, è possibile archiviarlo semplicemente come chiavi utilizzate per cercare gli oggetti, ma non negli oggetti stessi.

È difficile dare una risposta definitiva a una di queste domande senza conoscere / considerare tutti gli altri parametri di progettazione per questo progetto e il modo in cui potresti voler cambiare queste funzionalità in futuro.

score 1 · Answer 2

Now you could ask interesting questions like:

For each harbor give me a list of all cargo ships within a 100 km radius.

come memorizzare i risultati di determinate domande in memoria?

Ok, quindi stai lavorando con gli oggetti in memoria. Come ragionevole tipo di ritorno è uno dei seguenti tipi, qui in n C #:

Dictionary<Harbor,HashSet<Ship>>                      // concrete collection
IDictionary<Harbor,ICollection<Ship>>                 // interface-based collection
IReadOnlyDictionary<Harbor,IReadOnlyCollection<Ship>> // interface-based, immutable
IEnumerable<KeyValuePair<Harbor,IEnumerable<Ship>>    // enumerable-based collection

Java ha equivalenti simili.

Should I only keep the relations between the id's

Considera il consumatore che consuma e cosa farà dopo. Se togli le risposte dagli oggetti ai soli id, possiamo immaginare che in molte circostanze, dovranno interrogare l'oggetto dato un id, o se non vuoi distribuire l'oggetto, quindi interrogare gli attributi dell'oggetto dato l'id. Dovrebbe costare poco a nulla per restituire oggetti, che sono più direttamente utilizzabili (attributi prontamente disponibili) piuttosto che id.