La separation of concerns est un principe qui, au premier abord, ressemble beaucoup au principe de responsabilité unique. La separation of concerns établit que le code ne devrait jamais être broken up
into distinct sections, such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program. […] A program that embodies SoC well is called a modular program.
Dans différentes sections, telle que chaque section s'occupe d'une préoccupation différente. Une préoccupation est un ensemble d'informations qui affectent un programme informatique (…) Un programme qui utilise bien SoC est un programme modulaire.
Modulaire est un mot que vous connaissez certainement; l'idée de diviser des UI en un grand ensemble de petits éléments composables. La séparation des préoccupations est juste une définition formelle qui couvre les concepts de modularité et d'encapsulation dans le code. En CSS cela signifie construire des composants individuels, et écrire du code qui se focalise seulement sur une tâche à la fois.
Le terme a été inventé par Edsger W. Dijkstra, qui indiqua plutôt élégamment :
Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called ‘the separation of concerns’, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of. This is what I mean by ‘focusing one’s attention upon some aspect’: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
Laissez-moi essayer de vous expliquer cela, qui est pour moi caractéristique de toute pensée intelligente. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. Nous savons qu'un programme doit être correct et nous pouvons étudier depuis ce point de vue seulement; nous savons aussi qu'il doit être efficace et nous pourrions étudier son efficacité un autre jour pour ainsi dire. D'une autre manière, nous pourrions nous demander pourquoi ce programme est désirable. Mais rien n'est obtenu — au contraire — en s'attaquand à ces différents problème simultanément. c'est ce que j'appelle parfois la « séparation des préoccupations », ce qui, meêm s'il n'est pas totalement possible, est pourtant la seule technique disponible et que je connaisse pour organiser ses pensée. C'est cela que j'entend pas « focaliser son attention sur un aspect », cela ne signifie pas ignorer les autres aspects, je fais juste justice au fait que du point de vue d'un aspect, l'autre est hors de propos. It is being one- and multiple-track minded simultaneously.
C'est très beau. L'idée ici de se focaliser entièrement sur une chose à la fois; construire une chose pour faire très bien son travail tout en prêtant aussi peu attention que possible aux autres aspects de votre code. Une fois répondu séparemment en isolation à toutes ces préoccupations — signifiant qu'elles sont très modulaires, découplée, encapsulées — vous pouvez commencer à les intégrer à un plus grand projet.
Un bon exemple est le layout. Si vous utilisez un système de grille, tout le code se rapportant au layout devrait exister par lui-même, sans inclure quoique ce soit d'autre. Vous avez écrit du code qui gère le layout, et c'est tout :
<div class="layout"> <div class="layout__item two-thirds"> </div> <div class="layout__item one-third"> </div> </div>
Vous avez maintenant besoin d'écrire du code neuf, séparé pour gérer ce qui se passe dans ce layout :
<div class="layout">
<div class="layout__item two-thirds">
<section class="content">
...
</section>
</div>
<div class="layout__item one-third">
<section class="sub-content">
...
</section>
</div>
</div>
La séparartion des préoccupations vous permet que le code se suffise à lui même, et reste ignorant et enfin bien plus maintenable. Du code qui adhère à la séparation des préoccupations peut être bien plus aisément modifié, édité, étendu et mainteni car nous savons l'étendue de ses responsabilités. Nous savons que modifier le layout, par exemple, modifiera uniquement la layout — rien d'autre.
La séparation des préoccupations augmente la réutilisabilité et la confiance en le code tout en réduisant la dépendance.
Il y a, je pense, nombre d'idée fausses concernant la séparation des préoccupations lorsqu'appliquée au HTML et CSS. Il semblent tourner autour de la formulation :
There are, I feel, a number of unfortunate misconceptions surrounding the separation of concerns when applied to HTML and CSS. They all seem to revolve around some format of:
Utiliser des classes pour CSS rompt la séparation des préoccupations.
Malheureusement, cela est simplement faux. La séparation des préoccupations existebel et bien en HTML et CSS (et JS), mais pas de la manière dont les gens semblent le penser.
La séparation des préoccupations lorsque appliqué à du code front-end n'est pas question de classes-en-html-purement-comme-des-hook-pour-les-styles-brisant-la-séparation-des-préoccupations; il est simplement question du fait que nous utilisont des langages totalement différents pour le balisage et le style.
Avant que le CSS soit massivement adopté, nous utilisions des tables pour mettre le contenu en page, ldes élémens font avec des attributs color pour fournir des styles cosmétiques. Le problème est que le HTML était utilisé pour créer le contenu mais aussi pour le styler; il n'y avait pas moyen d'avoir l'un sans l'autre. Il y avait une absence totale de séparation entre les préoccupations, ce qui était le problème. Le travail du CSS était de fournir une syntaxe totalement nouvelle pour appliquer les styles, nous permettant de séparer contenu et styles au travers de deux technologies.
Un autre argument courant est que “mettre des classes dans votre html met des informations sur le style dans votre markup”.
Et donc, dans une tentative d'éviter cela, les personnes utilisent des sélecteurs qui ressemblent à ça :
body > header:first-of-type > nav > ul > li > a {
}
Ce CSS — visant probablement à styler notre nav principale — a le problème habituel de la dépendance de localisation, d'une piètre Selector Intent et une haute spécificité, mais s'arrange aussi pour faire exactement ce que les développeurs essaient d'éviter, mais dans l'autre sens : il met des informations sur le DOM dans le CSS. Les tentatives aggressives visant à éviter de mettre des indices ou hooks dans le markup ne mènent qu'à surcharger les feuilles de style avec des informations sur le DOM.
En bref : utiliser des classes dans votre markup ne viole pas la séparation des préoccupations. Les classes agissent tout au plus comme une API pour lier deux préoccupations ensemble. La meilleur manière de séparer les préoccupations et d'écrire du HTML et du CSS bien formés, et de lier les deux avec un usage raisonné et judicieux des classes.