È una violazione della singola responsabilità aggiungere un metodo a un'API esistente

4

Supponiamo che abbia un'API di riposo con un metodo POST e GET.

Se voglio sovrascrivere una risorsa nell'API, posso chiamare il metodo GET per ottenere l'elemento originale e quindi chiamare il metodo POST per sostituire quella risorsa dopo che ho finito di modificarlo.

Dovrei aggiungere la funzionalità di aggiornamento alla classe client come nel primo approccio o dovrei creare una nuova classe e aggiungere la funzionalità di aggiornamento e chiamare la classe client esternamente come nel secondo approccio

Primo approccio

class BookApiClient{

 Client restClient = ClientBuilder.newClient();

 public Book getBook(String id){

 // code to get book using rest client
 }

 public void postBook(){

 //code to post a book

 }


 public void updateBookTitle(String id, String newTitle){

  Book book = getBook(id);

  book.setTitle(newTitle);

  postBook(book);

 }

}

Secondo approccio

class BookUpdater{

 BookApiClient bookService;

 public BookUpdater(BookApiClient bookService){

   this.bookService = bookService;

 }

  public void updateBookTitle(String id, String newTitle){

  Book book = bookService.getBook(id);

  book.setTitle(newTitle);

  bookService.postBook(book);

 }

}

Sarebbe una violazione del principio di responsabilità singola aggiungere il metodo updateBookTitle alla classe client o farlo come un altro come nel secondo approccio

    
posta Claudiga 08.08.2018 - 18:05
fonte

2 risposte

6

Il primo approccio sembra buono e coerente. Non contraddice SRP: il principio della singola responsabilità non riguarda ciò che fa la classe, ma i suoi motivi per cambiare, come spiegato da Zio Bob (l '"inventore" di SRP) in questo eccellente articolo .

Inoltre, la tua API REST potrebbe offrire un PUT corretto invece del POST per una sostituzione completa (e PATCH per un aggiornamento parziale ). L'utilizzo del primo approccio avrebbe quindi il vantaggio di nascondere i dettagli dell'API e offrire un'interfaccia più semplice per la gestione dei libri.

Il BookAPIClient agirà quindi come facciata remota . L'unica ragione per cambiarlo sarebbe l'evoluzione dell'API del libro.

    
risposta data 08.08.2018 - 20:38
fonte
-1

Sì.

Il client dovrebbe preoccuparsi solo della comunicazione con il server. Dovrebbe avere solo metodi che il server offre. È solo, 'il motivo per cambiare' se vuoi, dovrebbe essere che il server è cambiato.

UpdateTitle aggiunge una logica aziendale aggiuntiva che dovrebbe trovarsi in un diverso livello dell'applicazione.

Cosa succede se, ad esempio, quando si aggiorna un titolo, si desidera scrivere anche un registro di controllo su auditClient? immetti ora il client di revisione in BookClient nel caso in cui venga chiamato un metodo? Dove finirà la pazzia?

Inoltre la tua richiesta di GET book dovrebbe usare un POST in caso di superamento della lunghezza massima dell'URL !!!

    
risposta data 08.08.2018 - 19:07
fonte

Leggi altre domande sui tag