Pro e contro per scegliere tra diversi tipi di ritorno

Question

Pro e contro per scegliere tra diversi tipi di ritorno

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

1

Questo è nel contesto di un'architettura client-server, anche se non penso che siano necessarie le impostazioni architettoniche per risolvere il problema.

Ho una funzione il cui output può essere classificato in diverse categorie:

function makeCar() { /* make a car */ }

Ora, per decidere la struttura per il valore di ritorno di makeCar , ho diverse opzioni:

Opzione 1

Restituisce valori interi e una struttura dati che associa i valori interi a diversi tipi di automobili.

Esempio:

    codeToCar = {
                 "1": {
                       "model": "Jaguar XJS", 
                       "color": "Black", 
                       "year": "1975"
                      }, 
                 "2": {
                       "model": "Chevrolet Camaro", 
                       "color": "Blue", 
                       "year": "1966"
                      } 
                 ...
                }

In questo caso, la funzione makeCar restituirebbe le chiavi di codeToCar .

Opzione 2

Restituisci l'oggetto auto stesso e elimina i codici interi.

Opzione 3

Restituisce una struttura ibrida con alcuni codici interi e alcuni valori specifici.

Esempio:

    codeToColor = {
                   "1": "Black", 
                   "2": "Blue", 
                   ...
                  } 

    codeToMaker = {
                   "1": "Jaguar", 
                   "2": "Chevrolet", 
                   ...
                  }

In questo caso, la funzione makeCar potrebbe restituire

   {
    "color": 2, 
    "maker": 1, 
    "model": "Camaro" 
   }

Quali sono i pro e i contro dell'uso delle diverse opzioni?

Modifica:

Credo che avrei dovuto elaborare il contesto di più. Quindi in pratica la funzione makeCar viene eseguita su un browser client e il valore di ritorno della funzione viene passato al server in una richiesta HTTP. Qualsiasi rappresentazione per il tipo di ritorno di makeCar sul lato client verrebbe alla fine tradotta in una rappresentazione dell'oggetto completo ( opzione 2 ) sul server.

I due parametri che ho scelto per il confronto tra le diverse opzioni sono:

Numero di byte trasferiti su HTTP
Estensibilità nel caso in cui vengano aggiunte nuove proprietà alle auto o aggiunti nuovi valori a una proprietà auto esistente.

I, tuttavia, sarebbe anche interessato a sapere quali altri parametri potrebbero essere usati ( nel contesto corrente ) per confrontare le opzioni disponibili, insieme alla scelta tra le diverse opzioni in base ai parametri scelti.

programming-practices return-type information-theory

posta Bharat Khatri 15.07.2014 - 11:25

fonte

2 risposte

Leggi altre domande sui tag programming-practices return-type information-theory

Altri requisiti in un singolo caso: corretto? URL con stringhe di query variabili e cache

score 1 · Answer 1

Questo non è specifico per restituire i tipi, stai solo chiedendo come rappresentare una macchina. La risposta dipende dalle proprietà delle auto che devi rappresentare, dal modo in cui queste proprietà variano e da ciò che fai con una macchina quando lo hai.

Non esiste un modo assoluto e perfetto per rappresentare oggetti fisici: scegli sempre un'astrazione e la scelta dipende da ciò che stai cercando di ottenere. Quindi, la risposta sarebbe diversa per un gioco di guida, da una simulazione fisica o da un sistema di inventario o di controllo delle scorte.

Se hai pochissime auto possibili, allora un indice in una matrice hard-coded potrebbe andare bene. Se le tue auto devono essere modificabili (ad esempio, cambiando il colore), è improbabile che un indice sia una buona scelta.

Se le tue auto sono solo oggetti di inventario e non hanno alcun comportamento, probabilmente una lista di proprietà piatte probabilmente va bene. Se devono fare qualcosa (come l'unità), allora forse ogni modello distinto potrebbe essere un sottotipo, ma il colore potrebbe ancora essere una proprietà (mutabile).

score 0 · Answer 2

Sicuramente non utilizzare # 1 perché allora hai bisogno di troppi codici per rappresentare tutte le possibili configurazioni di auto
Se si desidera utilizzare 3, è necessario sviluppare uno standard per tradurre tra il codice e le stringhe di denominazione effettive. Ciò funzionerebbe bene per molti problemi di parole reali poiché ci sono già molti standard consolidati per cose come i colori, gli ID di società, ecc. Questo può funzionare anche quando gli utenti vogliono un maggiore controllo e vogliono sviluppare il proprio frame di identificazione. / p>
Se utilizzi 2, rendi le cose più a forma libera che si adatterebbero meglio nel caso in cui gli standard non siano ben stabiliti, molti standard contrastanti, non vuoi sviluppare gli standard, non vuoi che l'utente sviluppi lo standard che li limiti in futuro. Particolarmente adatto quando i dati vengono utilizzati solo in superficie (come ad esempio una stringa di visualizzazione) con una logica aziendale minima dipendente da esso.

In altre parole, scegli 2 o 3. Devi specificare di più il tuo problema. Vorrei personalmente appoggiarmi al reparto 3 di quello che hai messo qui.