Séparation des préoccupations ( Separation Of Concern SOC)

La Séparation des préoccupations c'est quoi ?

En informatique, la séparation des responsabilités ou séparation des préoccupations (SoC Separation Of Content en anglais), est un principe de conception pour séparer un programme informatique en sections distinctes de telle sorte que chaque section aborde une préoccupation distincte. Il représente le "S" dans le principe solide. Une préoccupation est un ensemble d'informations qui affecte le code d'un programme informatique. Une préoccupation peut être aussi générale que "les détails du matériel d'une application", ou aussi spécifique que "le nom de la classe à instancier". Un programme qui incarne bien SoC est appelé programme modulaire. La modularité, et donc la séparation des préoccupations, est obtenue en encapsulant des informations dans une section de code qui a une interface bien définie. L'encapsulation est un moyen de cacher l'information. Les conceptions en couches dans les systèmes d'information sont un autre mode de réalisation de la séparation des préoccupations (par exemple, couche de présentation, couche de logique métier, couche d'accès aux données, couche de persistance).




La séparation des préoccupations entraîne plus de degrés de liberté pour certains aspects de la conception, du déploiement ou de l'utilisation du programme. Parmi ceux-ci, la liberté accrue de simplification et de maintenance du code est courante. Lorsque les préoccupations sont bien dissociées, les possibilités de mise à niveau, de réutilisation et de développement indépendant des modules sont plus nombreuses. Masquer les détails d'implémentation des modules derrière une interface permet d'améliorer ou de modifier la section de code d'une seule préoccupation sans avoir à connaître les détails des autres sections et sans avoir à apporter des modifications correspondantes à ces autres sections. Les modules peuvent également exposer différentes versions d'une interface, ce qui augmente la liberté de mettre à niveau un système complexe de manière fragmentaire sans perte de fonctionnalité provisoire.

La séparation des préoccupations est une forme d'abstraction. Comme pour la plupart des abstractions, séparer les préoccupations signifie ajouter des interfaces de code supplémentaires, créant généralement plus de code à exécuter. Ainsi, malgré les nombreux avantages de préoccupations bien séparées, il y a souvent une peine d'exécution associée.

2 - Quelques exemples de séparations des préoccupations

Commençons par un exemple un peu moins abstrait. Dans la programmation Web, il existe un principe de conception qui stipule que la mise en œuvre de votre site Web doit être séparée en trois domaines:

  1. Style & présentation - l'aspect visuel du site.
  2. Business Logic Layer (Couche Logique Métier) - la façon dont le site se comporte en réponse aux actions des utilisateurs.
  3. Contenu - les données réelles présentées, telles que le contenu ou les articles du  blog.

En suivant ces règles, on essaierait d'éviter de mélanger la logique métier et la présentation, et il en va de même pour le contenu. Si possible, ces éléments seraient contenus dans différentes sources ou fichiers de données; sinon, ils se trouveraient dans des sections distinctes et facilement identifiables du même fichier.

Il y a plusieurs bonnes raisons à cela:

La première est que ces éléments sont souvent modifiés indépendamment. Par exemple, vous souhaiterez peut-être de présenter le même contenu, avec la même logique métier, mais avec un style différent, ou bien vous pouvez présenter un contenu différent, mais avec le même style et la même logique. Garder ces éléments séparés permet de les remplacer facilement sans affecter les autres, surtout si les interactions entre eux sont formelles et bien définies - il suffit de brancher et de jouer!

Une autre raison est qu'il existe souvent différents rôles d'équipe associés à ces différents éléments. La personne en charge de la gestion du contenu n'est peut-être pas la même que celle qui conçoit l'apparence du site. La séparation des domaines permet aux individus de travailler librement sans marcher les uns sur les autres; cela signifie également qu'ils ne sont pas obligés de comprendre les parties du système qui ne sont pas liées à leur tâche. Ainsi, une personne dont le travail consiste à créer les feuilles de style pour le site n'a pas besoin d'apprendre à gérer une base de données de contenu également; les gens peuvent se spécialiser.

Une troisième raison est organisationnelle: la division de l'implémentation en éléments bien définis facilite la recherche de choses. Si vous essayez de savoir pourquoi le site se comporte d'une manière particulière, vous pouvez limiter votre recherche aux parties de la logique métier, vous n'avez pas à perdre de temps à regarder les fichiers source traitant de la présentation ou du contenu. Cela est conforme au principe général «rendre le code facile à raisonner».

Bien que cette règle particulière de séparation (style, logique, contenu) soit assez standard dans l'industrie du Web, ce n'est pas la seule séparation possible. En fait, j'ai déjà travaillé dans une startup qui faisait des logiciels bancaires; dans cet environnement, il y avait des rôles supplémentaires liés à des domaines tels que l'image de marque et la sécurité, chacun ayant son propre ensemble d'ingénieurs spécialisés. Malheureusement, la technologie à l'époque était trop primitive pour séparer tous ces éléments, ce qui signifiait que changer un élément nécessitait de démêler les détails de l'enchevêtrement de code.

De plus, la séparation en ces trois domaines ne doit pas être la seule séparation! Par exemple, si votre site Web a une page de connexion, une page de profil et une page de gestion de compte, celles-ci doivent également être séparées les unes des autres; et chacune de ces pages aura sa propre présentation, sa logique et ses éléments de contenu séparés des autres.




Voyons maintenant un autre exemple, qui est un serveur Web. Un serveur Web se compose généralement de plusieurs couches. Voici un arrangement possible:

Couche d'entrée: responsable de l'acceptation des demandes HTTP d'entrée, de leur validation pour l'authentification et le format appropriés, puis de leur répartition vers la fonction logique appropriée.
Couche logique - contient les algorithmes qui opèrent sur les données en réponse à l'entrée de l'utilisateur.
Couche d'accès aux données - chargée de lire et d'écrire des représentations en mémoire des enregistrements vers et depuis la base de données, ainsi que d'effectuer des requêtes complexes sur les données.

Encore une fois, l'organisation est telle qu'il est possible de connaître la couche dans laquelle se trouve un morceau de code donné, sans avoir à rechercher toutes les couches. Un avantage supplémentaire est que ces couches peuvent être testées unitairement isolément, permettant un régime de test plus simple et plus facile.

 

Younes Derfoufi
CRMEF OUJDA

Leave a Reply

Your email address will not be published. Required fields are marked *