Clean-Code

Accéder à r.width et écrire r.width = 15 avec la syntaxe d’un attribut normal, tout en exécutant de la validation ou du calcul derrière : c’est ce que @property apporte. Et quand cette logique doit se partager entre plusieurs classes, les descripteurs entrent en jeu. @property : getters et setters sans friction @property permet d’exposer un attribut calculé ou validé avec la même syntaxe qu’un attribut simple. class Rectangle: def __init__(self, width: float, height: float): self._width = width self._height = height @property def width(self) -> float: return self._width @width.setter def width(self, value: float) -> None: if value <= 0: raise ValueError("La largeur doit être positive.") self._width = value @property def area(self) -> float: return self._width * self._height L’avantage concret : l’API publique ne change pas. Ajouter de la validation sur un attribut existant ne casse aucun code appelant. @property sans setter crée un attribut en lecture seule. @nom.deleter gère la suppression via del. ...

Le couplage est souvent traité comme une notion vague : “c’est trop couplé” ne dit rien sur ce qu’il faut changer. La connascence propose un vocabulaire précis pour nommer les différentes formes de couplage, les comparer, et décider lesquelles réduire en priorité. Le concept est documenté en détail sur connascence.io. Trois axes pour évaluer une connascence Chaque instance de connascence s’analyse selon trois axes : Force : plus une connascence est forte, plus elle est difficile à détecter et à refactoriser. Degré : une entité couplée à des centaines d’autres est plus problématique qu’une entité couplée à deux. Localité : deux composants proches (même classe, même module) peuvent se permettre des formes plus fortes. À distance, ces mêmes formes deviennent dangereuses. Les 9 types de connascence Connascence de nom (CoN) Plusieurs composants s’accordent sur le nom d’une entité. C’est la forme la plus faible et la plus inévitable. ...