Laquelle des conceptions suivantes est considérée comme la meilleure pour une API et pourquoi?API Design - Utiliser l'objet ou la collection comme paramètre?
apiMethod(Map<A, B> aToB)
ou
apiMethod(MapWrapper<A, B> mapWrapper) où MapWrapper est simplement une classe contenant une référence à la carte.
Quels sont les avantages et les inconvénients des deux approches?
Vous recherchez toujours des API "minimalistes".
Dans ce cas: lorsque votre API fonctionne lors du passage d'un Map - alors, bien sûr, vous choisissez ce chemin. Pourquoi mettre le fardeau sur votre client à d'abord wrap cette carte ?!
Le pro de l'option 1 est - c'est le chemin direct.
Considérant que l'option 2 a seulement l'inconvénient de rendre plus difficile l'utilisation de l'API. En d'autres termes: si le central "propriété" de ce paramètre est "être une carte" - alors il devrait être passé en tant que carte. Mais quand le "thème central" est quelque chose de différent - alors vous passez quelque chose qui va le long de cet autre thème.
Je pense que l'utilisation d'un Map comme paramètre de l'API est une mauvaise pratique car il est très difficile de comprendre de quoi votre API a vraiment besoin. Dans un code ancien, j'ai trouvé comme méthode:
doSomeStuff(Session session){
String aa = session.get("aa");
String bb = session.get("bb");
return aa + bb;
}
Le refactoring de ce code sera:
doSomeStuff(String aa, String bb){
return aa + bb;
}
et vous savez que vous devez appeler votre API aa et bb.
Je préférerais avoir une classe de modèle comme paramètre, plutôt qu'une 'Map' générique. 'MapWrapper' n'a pas non plus de sens - quelle valeur ajoutée aurait-il sur' Map'? – lexicore
Le premier, l'ajout d'un wrapper n'a aucun sens. Probablement un meilleur design que l'utilisation d'une carte est possible. – Oleg
Quelle est la responsabilité de cette carte? – Andrew