Dove si trova la logica per rispettare SRP qui?

3

Sto lavorando su una semplice classe per ottenere un token da un'API. Per quanto semplice, ha aspetti diversi.

  • È necessaria una connessione all'API affinché funzioni almeno la prima volta. Le credenziali sono memorizzate nel codice (la sicurezza non è l'argomento).
  • Un token non deve essere prelevato dall'API più di una volta ogni 9 ore, quindi deve essere salvato in un file quando viene recuperato con successo.
  • Se il file è troppo vecchio, deve essere generato nuovamente.

Ora sto pensando di fare quattro classi:

  • File : responsabile della creazione, sovrascrittura e restituzione del file.
  • Parser : responsabile dell'analisi di un file ricevuto.
  • DateCheck : responsabile per verificare se il token è troppo vecchio o non
  • Connessione : responsabile del recupero del token tramite l'API, se necessario,

Ora tutte queste classi vanno bene (cosa ne pensi?), ma ovviamente ho bisogno di una classe di livello superiore ad un certo punto per racchiudere tutta questa logica e ottenere il token con una semplice chiamata a questa classe.

In primo luogo ci saranno 4 dipendenze, non è troppo? Inoltre, farà davvero molte cose e il motivo per cui è fastidioso per me è perché i test unitari sono piuttosto grandi (15-30 linee) con tutte le derisioni richieste, e la maggior parte dei test in codice di progetti di successo che ho letto sono molto piccolo e semplice da capire.

C'è qualcosa di sbagliato in questo ragionamento, o è la rovina che divide le cose così tanto?

    
posta Steve Chamaillard 05.10.2016 - 11:37
fonte

1 risposta

4

Sembra che tu stia commettendo un classico errore di progettazione OOP: ti stai concentrando su "cose" anziché su "comportamento". Nel tuo caso, ci sono tre comportamenti: Fetching il token, Caching il token e Persisting il token. C'è anche una bella astrazione: perché il cliente non dovrebbe preoccuparsi di dove o come viene ricevuto il token, può usare Fetching e Caching in modo intercambiabile.

Quindi il design sarebbe simile a questo:

In questo modo, il client utilizza solo l'interfaccia e non gli interessa se il token è memorizzato nella cache o meno. Inoltre, puoi introdurre diversi modi per recuperare il token e mantenere la memorizzazione nella cache, poiché la memorizzazione nella cache è solo un decoratore. Vorrei anche dire che non è necessario per le classi come le hai progettate, e basta inserire il codice all'interno delle classi come nel mio design.

E se vuoi essere davvero fantasioso, puoi introdurre un'altra astrazione per mantenere il token, ma complicherà il disegno con facilità se hai una sola modalità di persistenza.

    
risposta data 05.10.2016 - 12:41
fonte

Leggi altre domande sui tag