The Open/Closed Principle
Le open/closed principle est, à mon avis, piètrement nommé. cela car 50% des informations vitales sont omises de ce titre. Le open/closed indique que :
[s]oftware entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Vous voyez ? Les mots les plus importants — extension et modification — sont complètement manquants dans le nom, ce qui ne sert pas celui-ci du tout.
Une fois que vous vous serez entrainé à vous souvenir à quoi les termes ouvert et fermé sont liés, vous trouverez le principe d'ouvert/fermé remarquablement simple: tout fonctionnalité, ou feature que nous ajoutons doit l'être par extension — Nous ne devrions jalmais avoir besoin de modifier une abstraction — on arrête simplement de l'utiliser — mais toute variante même légère peut être faite très facilement en l'étendant.
Prenons un exemple :
.box {
display: block;
padding: 10px;
}
.box--large {
padding: 20px;
}
Nous pouvons voir ici que l'objet .box {} est incroyablement simple : we’ve stripped it right back into one very small and very focussed responsibility. Pour modifier cette boite, nous l'étendons avec une autre classe; .box–large {}. Ici la classe .box {} est close à toute modification mais ouverte à l'extension.
Une manière incorrect de faire la même chose pourrait ressembler à :
.box {
display: block;
padding: 10px;
}
.content .box {
padding: 20px;
}
Non seulement c'est bien trop spécifique, dépendant à la localisation et montrant potentiellement une piètre Selector Intent, et l'on modifie .box {} directement. Nous devrions rarement, si cela devait arriver, trouver une classe d'objet ou d'abstraction comme sélecteur clé dans un sélecteur composé.
Un sélecteur composé tel .content .box {} est potentiellement source de problème car :
- Il force tous les composants .box à appliquer ce style lorsque placé dans .content, ce qui signifie que la modification est imposée aux développeurs, alors que les développeurs devraient avoir la possibilité d'une adoption explicite.
- Le style .box est maintenant imprévisible pour les développeurs; la responsabilité unique n'existe maintenant plus à cause du sélecteur niché qui produces a forced caveat.
Toute modification, addition, et changement devrait toujours être en opt-in et non obligatoire. Si vous pensez que quelque chose peut nécessiter un léger ajustement le faisant dévier de la norme, fournissez une nouvelle classe ajoutant cette fonctionnalité.
Lorsque l'on travaille dans un environnement en équipe, soyez sûrs d'écrire du CSS API-like; assurez vous toujours que les classes existantes restent rétrocompatibles (pas de changement à leur racine) et fournissent de nouveaux hooks pour amener de nouvelles fonctionnalitées. Changer la racine de l'objet ou abstraction, ou du composant peut être extrêmement problématique pour des développeurs qui réutiliserait ce code ailleurs, ne modifiez donc jamais du code existant directement.
Des exceptions peuvent apparaître lorsqu'un objet racine a besoin d'être réécrit ou refactoré, mais c'est seulement dans ces cas spécifiques que vous devriez modifier du code. Souvenez-vous : ouvert à l'extension, fermé à la modification.