Comment expliquez-vous la séparation des préoccupations aux autres?

Imaginez que vous avez un programme qui a été publié. Un client arrive et vous propose de vous payer pour une amélioration de lune de ses fonctionnalités. Afin dobtenir de largent, vous devrez changer votre programme pour ajouter la nouvelle fonctionnalité. Voici quelques-uns des facteurs qui influenceront votre marge bénéficiaire:

1. la quantité de code à modifier
2. la facilité d’effectuer les modifications
3. quelle est la probabilité que vous interrompiez les fonctionnalités existantes utilisées par dautres clients
4. dans quelle mesure vous pouvez réutiliser votre modèle / architecture existant

La séparation des préoccupations aide vous pour obtenir des réponses plus positives à ces questions.

1. si tout le code dun comportement particulier de lapplication est séparé, vous naurez plus quà changer le code directement associé à votre nouvelle fonctionnalité . Ce qui devrait être moins de code à changer.
2. si les comportements qui vous intéressent sont parfaitement séparés du reste de lapplication, il est plus probable que vous puissiez échanger une nouvelle implémentation sans avoir à bien comprendre ou manipuler le reste du programme. Il devrait également être plus facile de savoir quel code vous devez changer.
3. Le code que vous navez pas à modifier est moins susceptible de se casser que le code que vous modifiez. Donc, diviser les problèmes vous aide à éviter la rupture de fonctionnalités non liées en vous évitant davoir à changer le code quils pourraient appeler. Si vos fonctionnalités sont mélangées, vous risquez de changer le comportement de lune dentre elles par accident en essayant den changer une autre.
4. Si votre architecture est indépendante des détails de la logique technique ou métier, les changements de mise en œuvre sont moins susceptibles de nécessiter nouvelles caractéristiques architecturales. Par exemple, si la logique de votre domaine principal est indépendante de la base de données, la prise en charge dune nouvelle base de données devrait être aussi simple que le remplacement dune nouvelle implémentation de la couche de persistance.

Commentaires

• Jadore que vous ayez fait la réponse fermement ancrée dans la réalité financière. Les managers nont aucune excuse pour être négligents et ignorer ce concept fondamental.

Regardez un hôpital, et Pensez à 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 tous de ces gens font leur travail? Non, car 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.

Sil / elle 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 divisés en fonction de leur travail?

Je regarderais comment il na pas appliqué le SoC dans son code / conception et je le transformerais en un exemple réel avec lequel il peut sidentifier et cest évidemment indésirable.

Par exemple, sil a une classe où le client doit fournir plusieurs informations qui ne sont pas pertinentes pour ces clients, alors jutiliserais lanalogie dune boulangerie où vous avez pour apporter vos propres céréales et levure si vous voulez acheter un pain.

Un exemple pourrait être un développeur HTML. voulez séparer html, css et javascript en separa te fichiers. De cette façon, vous pouvez changer lapparence et la sensation de quelque chose en modifiant simplement le css ou le comportement de quelque chose en changeant le fichier javascript qui est chargé séparément. Si vous avez un site réactif ou adaptatif, ce paradigme fonctionne bien car vous pouvez charger différents css ou javascript en fonction de la fenêtre des utilisateurs ou de lagent utilisateur. Cependant, si vous modifiez le html ou le modèle, il est probable que le css ou le javascript se cassent. Ces préoccupations distinctes peuvent également être dépendantes.

Une autre approche consiste à regrouper tous vos javascript et html css dans un groupe de composants ou de modules. Cela signifie que vous pouvez apporter des modifications à un module et que cela ne devrait pas affecter les autres composants ou modules de la page sur laquelle il sexécute et qui ne sont pas liés. Ici, les fichiers css, js et html sont fusionnés en un seul composant qui peut être testé unitaire.Ainsi, la séparation des préoccupations se présente sous la forme de composants atomiques individuels qui peuvent être testés unitairement plutôt que dune séparation des éléments de balisage, de style et de comportement. Cette seconde approche est plus adaptée à la création dapplications Web plus complexes.

edit. Depuis que jai reçu une réponse négative à ce commentaire, jai pensé que jallais le revoir et essayer de qualifier certains de mes pov. Malheureusement, les commentaires ici ne sont pas particulièrement constructifs, mais jai vu ailleurs une discussion intéressante qui examine React, la technologie actuelle du développement Web, un exemple du monde réel, et demande si cela rompt la séparation des préoccupations ou en particulier si cela brise lun des les principes de la méthodologie de conception orientée objet SOLID de Feather.

La perspective technique du développeur JavaScript

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

La page contient é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 de séparer les préoccupations dans lapplication de langage plutôt que séparer les préoccupations du framework, cest-à-dire les modèles, css et javascript, etc.

En ce qui concerne la séparation de vos préoccupations dans la langue de votre application, cela pourrait impliquer lutilisation de divers modèles pour séparer ou découpler votre code sous forme modulaire qui peut être testé unitaire, etc.

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

Commentaires

• cela ne ‘ ne semble pas offrir quoi que ce soit de substantiel par rapport aux points soulevés et expliqués précédemment 7 réponses
• Je signale simplement que séparer les préoccupations peut prendre différentes approches selon le contexte. Cest plus proche dune situation du monde réel dans les sternes du génie logiciel et je souligne quil existe différentes approches que vous pouvez adopter lorsque vous travaillez sur des pages html qui peuvent au premier abord sembler contradictoires.