json

# json

Posté par barmic 🦦 le 03 juillet 2021 à 16:30. En réponse au journal Separation of Concerns (SoC). Évalué à 9.
```
public static List<BookJson> toJson(Collection<Book> availableBookSet) {
 return availableBookSet.stream()
 .map(BookJsonHelper::toJson)
 .sorted(Comparator.comparing(BookJson::getTitle))
 .collect(Collectors.toList());
}
```
toJson() tris les livres ? Ça ne contrevient pas à la séparation des responsabilités ? En plus le tris sur le DTO qui est moins riche.

En fait je ne vois pas l'intérêt de cette méthode : elle fait trop de chose, elle n'est pas très flexible, si vraiment je voulais faire de l'overengenering, je ferrais un Collector qui par d'un Stream<Book> et qui produit soit un List<BookJson> soit un Optional<List<BookJson>.

Comme ça je pourrais avoir :
```
@GetMapping("/books/available")
public ResponseEntity<List<BookJson>> getAvailableBooks() {
 retrun modelLibraryService.getAvailableBooks()
 .stream()
 // le tris qui pour moi fait parti du domaine
 .sorted(Comparator.comparing(Book::getTitle))
 // mapping vers les DTP
 .collect(BookJsonHelper.dtoCollector())
 // aspect technique de la reponse json
 .map(ResponseEntity::ok)
 .orElseGet(ResponseEntity.noContent()::build);
}
```
Un truc qui pour moi peut aider à séparer ce qu'on fait c'est de se demander ce qu'il se passe quand on ajoute ou change une fonctionnalité. Si demain l'API doit fournir un paramètre pour choisir l'ordre ou pour limiter le nombre de résultat, qu'est-ce que je dois changer ?

Faire le tris dans le toJson() peut s'expliquer si le tris paraît être un invariant d'une liste de livre (les livres sont naturellement et sauf cas exceptionnels toujours triés par titre), mais dans ce cas là les livres devraient être comparables sans avoir besoin de paramètre au sorted()

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

# json