Comment expliquez-vous la séparation des préoccupations aux autres?
Si vous aviez un collègue qui ne comprenait pas les avantages de la séparation des préoccupations ou ne le comprenait pas assez pour s'appliquer de manière cohérente dans son travail quotidien, comment pourriez-vous lui expliquer cela?
Imaginez que vous ayez un programme qui a été publié. Un client arrive et vous propose de vous payer une amélioration de l'une de ses fonctionnalités. Afin d'obtenir de l'argent, vous devrez modifier votre programme pour ajouter la nouvelle fonctionnalité. Certaines des choses qui influeront sur votre marge bénéficiaire sont:
- combien de code vous devez changer
- combien il est facile de faire les changements
- la probabilité que vous cassiez des fonctionnalités existantes utilisées par d'autres clients
- combien vous pouvez réutiliser votre modèle/architecture existant
La séparation des préoccupations vous aide à obtenir des réponses plus positives à ces questions.
- si tout le code d'un comportement particulier de l'application est séparé, vous n'aurez qu'à modifier le code directement associé à votre nouvelle fonctionnalité. Ce qui devrait être moins de code à changer.
- si les comportements qui vous intéressent sont bien séparés du reste de l'application, il est plus probable que vous puissiez échanger une nouvelle implémentation sans avoir à comprendre ou manipuler entièrement le reste du programme. Il devrait également être plus facile de savoir quel code vous devez modifier.
- Le code que vous n'avez pas à modifier est moins susceptible de se casser que le code que vous modifiez. Ainsi, la division des préoccupations vous aide à éviter la rupture de fonctionnalités non liées en vous évitant d'avoir à modifier le code qu'elles pourraient appeler. Si vos fonctionnalités sont mélangées, vous pouvez modifier le comportement de l'une par accident en essayant d'en changer une autre.
- Si votre architecture est indépendante des détails techniques ou de la logique métier, les changements d'implémentation sont moins susceptibles de nécessiter de nouvelles fonctionnalités architecturales. Par exemple, si votre logique de domaine principal est indépendante de la base de données, la prise en charge d'une nouvelle base de données devrait être aussi simple que l'échange dans une nouvelle implémentation de la couche de persistance.
Regardez un hôpital et pensez à tous les différents rôles impliqués dans la prestation des soins à un patient: infirmières de triage, médecins, assistants médicaux, techniciens, personnel de bureau, cafétéria, etc.
Y a-t-il une personne qui sait comment toutes ces personnes font leur travail? Non, car ce serait écrasant. Ils doivent séparer les différentes responsabilités en rôles distincts et les points de contact entre ces rôles sont très spécifiques.
S'il travaille dans un bureau, prenez-le comme exemple, expliquez le rôle de chaque membre du personnel dans ce bureau et demandez-lui ce qui se passerait si ces membres du personnel n'étaient pas répartis en fonction de leur travail?
Je regarderais comment il n'a pas réussi à appliquer le SoC dans son code/conception et en ferais un exemple réel avec lequel il peut se rapporter et qui n'est évidemment pas souhaité.
Par exemple, s'il a une classe où le client doit fournir plusieurs informations qui ne sont pas pertinentes pour ces clients, j'utiliserais l'analogie d'une boulangerie où vous devez apporter vos propres céréales et levures si vous voulez acheter un pain.