Mes classes de service ont tendance à avoir tout à fait quelques variables d'instance ...
Ce n'est pas nécessairement une odeur de code. Si votre service nécessite de nombreuses dépendances pour terminer son travail, alors c'est simplement un fait.
... ils semblent faire beaucoup de travail (c'est-à-dire ont beaucoup de méthodes). Est-il conseillé de créer des services plus ciblés?
En règle générale, plus granulaire, vous pouvez faire vos interfaces de service (à savoir les moins méthodes), plus (jamais dû chaluter par une interface avec une cinquantaine de méthodes sur elle à la recherche de celui que vous voulez appeler?). Mais à moins que vous ne publiez en tant qu'API publique, la granularité de vos interfaces de service peut être affinée au fur et à mesure. Souvent, lorsque je démarre un projet, je commence avec un seul service et je le divise au fil du temps. Si vous êtes le consommateur de ces services, alors quand vous commencez à ressentir la douleur d'une interface, vous saurez qu'il est temps de le casser. Bien sûr, si cette est une API publique, alors vous devrez faire beaucoup plus de conception initiale.
De même, les classes de service devraient-elles stocker les variables d'instance dans d'autres entités? J'ai lu quelque chose au sujet des services étant apatrides, je ne suis pas sûr si je brise cette règle en ayant ces variables d'instance.
Le stockage de dépendances en tant que variables d'instance n'implique pas nécessairement que votre service n'est pas sans état, tant que les variables d'instance sont également sans état. Pour être considérés comme apatrides, les appels de méthode sur un service ne doivent en aucun cas dépendre des méthodes précédentes ayant été appelées. Vous devriez pouvoir charger une seule instance de service et la partager pour votre application (c'est-à-dire qu'une instance d'un service sans état ne devrait pas être spécifique à la session d'un utilisateur particulier). En d'autres termes, votre service ne doit pas conserver d'état entre les appels de méthode. Le stockage d'une dépendance de référentiel sans état en tant que variable sur une instance de service ne viole pas cette exigence.
La raison pour laquelle les services sans état est un objectif souhaitable, est de n'avoir aucun état réduit considérablement la possibilité de bogues.Il simplifie le test d'une méthode de service en limitant les cas de test à la variation des paramètres transmis, plutôt que de devoir se préoccuper de l'état précédent du service. Il peut également offrir des avantages de performance.
Merci pour la bonne réponse MJ! Cela aide beaucoup. – chobo
@MJ Richardson Pouvez-vous partager votre identifiant d'email (le mien est ajouté au profil)? J'ai quelques doutes que je voudrais clarifier concernant cet article. –