Design API pubblica - Stringa o tipo generico?

Naviga le tue risposte
0

Il mio team deve progettare un'API che invii oggetti a una coda nel cloud e recuperi gli oggetti da esso. I dati vengono inseriti nella coda come byte[] .

Fino ad ora abbiamo 2 idee che mi piacerebbe sentire i tuoi appunti / idee su di loro:

Prima versione:

  • public void push(String object)
  • public String retrieve()

Note: per supportare questa API, ogni consumatore deve implementare una logica per convertire i suoi oggetti in String s e viceversa.

I vantaggi:

  1. Facile da implementare.
  2. Facile da mantenere.

Svantaggi:

  1. Il consumatore della nostra API deve progettare una soluzione che non sia correlata alla sua logica per convertire i suoi oggetti in String s.
  2. Il consumatore della nostra API deve chiamare un metodo che converte i suoi oggetti da solo anche se non è correlato alla sua logica.

Seconda versione:

  • public void <T> push(T object)
  • public T <T> retrieve(Class<T> type)

I vantaggi:

  1. Facile da implementare. (In Java, possiamo usare ObjectMapper )
  2. Facile utilizzo di questa API.
  3. Il consumatore della nostra API non ha bisogno di convertire manualmente i suoi oggetti in qualcos'altro.

Svantaggi:

  1. I tipi di utenti della nostra API devono supportare% conversioni diJson - in modo ricorsivo, una classe con proprietà dell'oggetto, tutti i tipi di proprietà devono supportare% conversioni diJson.
  2. Se il consumatore non legge attentamente la documentazione, qualcosa non funzionerà o ci sarà un bug silenzioso.

Note generali:

  1. L'API deve essere supportata per almeno 4 anni.
posta Stav Alfi 19.02.2018 - 10:32
fonte

2 risposte

2

C'è un svantaggio potenzialmente trascurato con il secondo approccio, e cioè se la classe cambia dal momento in cui è stata inserita nell'ora in cui è stata recuperata, la deserializzazione fallirà.

Potresti lanciare un'eccezione appropriata per rendere l'errore chiaro, ma anche tu non saresti in grado di fare nulla al riguardo. Il chiamante potrebbe conoscere chiaramente l'errore, ma il chiamante stesso non sarebbe in grado di fare nulla al riguardo, avendo solo la versione più recente della classe. Per poter utilizzare quell'interfaccia, dopo ogni modifica alla classe, deve esserci una classe del convertitore che recuperi tutte le vecchie istanze di quella classe, distrugge quell'istanza nel cloud, quindi la ricrea usando la nuova versione della classe.

Non è un'impresa da poco. Se si desidera adottare questo approccio, è consigliabile prendere in considerazione una possibilità di aggiornamento che lo fa per conto del chiamante.

La tua prima soluzione, nonostante sia un po 'scomoda, è più robusta. Non è probabile che fallirà, il che potrebbe essere importante. Puoi avere entrambe le opzioni se lo desideri, nulla ti impedisce di farlo, lasciandolo al chiamante che usare. Almeno nel caso in cui una versione precedente viene salvata, esiste l'opzione di recuperare il valore di stringa della deserializzazione fallita da affrontare in un secondo momento.

    
risposta data 19.02.2018 - 15:07
fonte
3

Vorrei fare la seconda opzione, ma consentire all'utente di iniettare il proprio serializzatore / deserializzatore.

Genera eccezioni quando la serializzazione non riesce a evitare il tuo problema di errore silenzioso.

Dato che stai persistendo come byte [] potrebbe essere meglio serializzarlo su uno per evitare problemi con i set di caratteri.

    
risposta data 19.02.2018 - 11:15
fonte

Leggi altre domande sui tag

Diagramma di stato UML per N numero di approvazioni Quando Pythonic non usa le proprietà invece di un metodo che non accetta argomenti?