Qu'est-ce que la séparation entre la politique et le mécanisme?
L'article de Wikipedia sur séparation du mécanisme et de la politique dit
La séparation du mécanisme et de la politique est un principe de conception en informatique. Il stipule que les mécanismes (les parties d'une mise en œuvre d'un système qui contrôlent l'autorisation des opérations et l'allocation des ressources) ne doivent pas dicter (ou restreindre excessivement) les politiques selon lesquelles les décisions sont prises concernant les opérations à autoriser et les ressources à allouer. .
Quelle est la différence entre le principe de conception de la séparation du mécanisme et de la politique et le principe de la séparation de l'interface et de la mise en œuvre (comme dans SOLID)?
Une politique est-elle une interface?
Un mécanisme est-il une mise en œuvre d'une politique?
Qu'est-ce qui change le plus fréquemment avec le temps, la politique, le mécanisme ou les deux?
Le principe de la séparation de la politique et du mécanisme permet-il à la politique et au mécanisme de changer indépendamment les uns des autres? (La séparation de l'interface et de l'implémentation permet de modifier l'implémentation sans affecter l'interface et donc sans affecter le client.)
Quelle est la différence entre le principe de conception de la séparation du mécanisme et de la politique et le principe de la séparation de l'interface et de la mise en œuvre?
Ils n'ont rien à voir les uns avec les autres, il est donc difficile de décrire la différence entre eux.
La séparation de l'interface et de la mise en œuvre est "je n'ai pas besoin de savoir comment fonctionne la voiture pour la conduire". Si vous savez conduire un hayon à traction avant à essence et que l'on vous demande de conduire un coupé à traction arrière électrique, les performances peuvent être différentes de celles auxquelles vous êtes habitué, mais vous utilisez essentiellement essentiellement la même volant et pédales et interrupteurs d'éclairage et ainsi de suite pour faire fonctionner les deux véhicules, même si leurs détails de mise en œuvre sont complètement différents. Vous ne remarquez la différence que lorsque vous avez des interactions avec le véhicule qui ont des dépendances d'implémentation, comme le ravitaillement.
La séparation du mécanisme de la politique est que la voiture est conçue pour parcourir jusqu'à 100 miles par heure dans n'importe quelle direction, et le conducteur est responsable de suivre le bon chemin sur l'autoroute dans la bonne voie à la bonne vitesse, pas le voiture. Les politiques concernant la limite de vitesse et le moment où vous êtes autorisé à tourner à gauche ne sont pas intégrées dans le moteur, sauf dans la mesure où les moteurs ont été conçus par des personnes qui savaient quelles politiques seraient adoptées.
Maintenant, vous vous demandez peut-être ce qui se passe lorsque les voitures deviennent autonomes, et la réponse est: nous continuons à maintenir la séparation entre la politique et le mécanisme dans la conception du logiciel. Les choix quant au moment de freiner et quand accélérer sont faits en les encodant dans un code de politique qui a un contrôle exécutif sur les sous-systèmes qui dirigent la voiture, actionnent les freins, etc. Ces sous-systèmes de mécanismes ne connaissent pas ou ne se soucient pas de la politique; ils font juste ce qu'on leur dit.
Je suis fermement convaincu que le code du mécanisme doit être distinct du code de la politique. Voici une autre façon de penser: le code de politique décrit ce que fait le code au niveau du domaine métier. "Produire une liste triée des noms de famille de tous nos clients à Londres" relève du domaine des affaires. "Échanger ces deux éléments en panne dans ce tableau" est dans le domaine du mécanisme. Le domaine du mécanisme implémente la politique, mais il ne code la politique. Il encode des faits sur éléments du tablea, pas sur listes de diffusion client. Lorsque le code mélange les domaines de mécanisme et de stratégie, il devient plus difficile de raisonner et de maintenir.
Le concept de séparation entre politique et mécanisme est complètement orthogonal à l'idée d'interface et de mise en œuvre. Prenons une analogie:
Imaginez un bourreau, le genre dans une cagoule avec une grosse hache. Son travail consiste à couper la tête. Mais à qui exactement? C'est à la reine. Dans cette analogie, le bourreau est le mécanisme, la reine établit la politique. Vous n'avez pas le bourreau qui décide qui est exécuté.
Maintenant, l'interface pour cela est que la reine fait en quelque sorte connaître sa décision. Elle crie peut-être "avec sa tête!". Voilà l'interface. Ensuite, il y a un processus par lequel quelqu'un trouve le bourreau et le rassemble avec le malheureux pour faire l'acte. Voilà l'implémentation.
Pour résumer la politique par rapport au mécanisme, il faut garder la partie du système qui est responsable de la prise de décisions distincte de la partie qui les applique. L'interface et l'implémentation consistent à séparer la façon dont les parties du système communiquent entre elles de la façon dont elles réagissent aux messages des autres parties du système.
Les mécanismes doivent, par nécessité, être contrôlés par des personnes possédant une expertise considérable en programmation ou en systèmes, tandis que les politiques doivent être contrôlables par des personnes qui n'ont pas une telle expertise.