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 le comprenait assez peu pour l'appliquer de manière cohérente dans son travail quotidien, comment le lui expliqueriez-vous?

Imaginez que vous ayez un programme qui a été publié. Un client arrive et propose de vous payer pour 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é. Certains des facteurs qui influenceront votre marge bénéficiaire sont les suivants:

1. combien de code vous devez changer
2. comme il est facile de faire les changements
3. quelle est la probabilité que vous cassiez des fonctionnalités existantes utilisées par d'autres clients
4. 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.

1. si tout le code correspondant à un comportement particulier de l'application est séparé, il vous suffira de modifier le code directement associé à votre nouvelle fonctionnalité. Ce qui devrait être moins de code à changer.
2. Si les comportements qui vous intéressent sont bien séparés du reste de l'application, vous aurez plus de chances de pouvoir échanger une nouvelle implémentation sans avoir à comprendre ou à manipuler complètement le reste du programme. Il devrait également être plus facile de savoir quel code vous devez changer.
3. Le code que vous ne devez pas changer est moins susceptible de se briser que le code que vous modifiez. Par conséquent, la division des préoccupations vous aide à éviter les ruptures de fonctionnalités non liées en vous évitant de devoir modifier le code qu'ils pourraient appeler. Si vos fonctionnalités sont mélangées, vous pouvez modifier le comportement de l'une par accident tout en essayant d'en changer une autre.
4. Si votre architecture ne tient pas compte des détails techniques ou de la logique commerciale, les modifications d’implémentation sont moins susceptibles de nécessiter de nouvelles fonctionnalités architecturales. Par exemple, si la logique de votre domaine principal est agnostique à la base de données, la prise en charge d'une nouvelle base de données doit être aussi simple que l'échange d'une nouvelle implémentation de la couche de persistance.

Examinez un hôpital et réfléchissez à tous les différents rôles impliqués dans la prestation de 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 accomplissent leur travail? Non, parce que ce serait accablant. 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 / elle travaille dans un bureau, prenez-le comme exemple, expliquez le rôle de chaque membre du personnel de ce bureau et demandez-lui ce qu'il se passerait si ces membres du personnel n'étaient pas divisés en fonction de leurs tâches.

Je voudrais voir comment il a échoué à appliquer SoC dans son code / design et en faire un exemple du monde réel avec lequel il peut se rapporter, ce qui est évidemment indésirable.

Par exemple, s'il a une classe où le client a besoin de fournir plusieurs informations qui ne sont pas pertinentes pour ces clients, j'utiliserais alors l'analogie d'une boulangerie où vous devez apporter vos propres céréales et levure si vous voulez acheter. un pain.

Par exemple, un développeur HTML pourrait vouloir séparer html, css et javascript en fichiers séparés. De cette façon, vous pouvez changer l'apparence de quelque chose en modifiant simplement le css ou le comportement de quelque chose en modifiant le fichier javascript chargé séparément. Si vous avez un site adaptatif ou réactif, ce paradigme fonctionne bien car vous pouvez charger différents fichiers CSS ou JavaScript en fonction du viewport d'un utilisateur ou d'un agent utilisateur. Cependant, si vous modifiez le code HTML ou le modèle, il est probable que css ou javascript se brisent. Ces préoccupations distinctes peuvent également être dépendantes.

Une autre approche consiste à regrouper tous vos fichiers JavaScript et HTML css dans un groupe de composants ou de modules. Cela signifie que vous pouvez modifier un module et que cela ne devrait pas affecter les autres composants ou modules de la page sur laquelle il est exécuté, qui ne sont pas liés. Ici, les fichiers css, js et html sont fusionnés en un seul composant pouvant être testé en unité. Ainsi, la séparation des préoccupations se présente sous la forme de composants atomiques individuels qui peuvent être testés à l'unité plutôt que de séparer les éléments de balisage, de style et de comportement. Cette seconde approche est plus adaptée à la création d’applications Web plus complexes.

modifier. Depuis que j'ai reçu une réponse négative à ce commentaire, j'ai pensé pouvoir le revoir et essayer de qualifier une partie de mon pov. Malheureusement, tout retour d’information ici n’est pas particulièrement constructif, mais j’ai vu une discussion intéressante ailleurs qui se penche sur React, la technologie de pointe actuelle dans le développement Web, un exemple concret, et demande s’il brise la séparation des préoccupations ou en particulier l’un des les principes de la méthodologie de conception orientée objet SOLID de Feather.

La perspective des développeurs JavaScript techniques

NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own      architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.

La perspective du concepteur UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.

La perspective de l'équipe

NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working    directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

Sur la page se trouve également un lien vers une présentation intéressante de Pete Hunt, de Facebook, où il parle de composants et non de modèles, et sépare les problèmes de l’application linguistique plutôt que de séparer ceux du framework, à savoir modèles, css et javascript. etc.

Pour séparer vos préoccupations dans la langue de votre application, vous devrez peut-être utiliser différents modèles pour séparer ou découpler votre code en une forme modulaire pouvant être testée, etc.

Donc, pour résumer, la séparation des préoccupations peut dépendre de votre rôle ou de votre point de vue, comme mentionné ailleurs.