Architecture

Le code métier ne doit pas dépendre des détails techniques : les deux doivent dépendre d'abstractions. Inversion ou injection de dépendances ? Un exemple complet, testable sans base de données ni serveur de mail.

Aucun client ne devrait dépendre de méthodes qu'il n'utilise pas. Comment une interface fourre-tout finit par imposer des méthodes inutiles, et comment la découper en petites interfaces taillées pour leurs utilisateurs.

Une classe enfant doit pouvoir remplacer sa classe parente sans mauvaise surprise. Le fameux carré qui n'est pas un rectangle, les règles du contrat et les signes qui trahissent un héritage bancal.

Ajouter une fonctionnalité sans toucher au code qui marche déjà : c'est la promesse du principe ouvert/fermé. Démonstration avec des modes de livraison, une interface et un peu de polymorphisme.

Une classe ne devrait avoir qu'une seule raison de changer. Ce que cette phrase veut vraiment dire, comment repérer une classe qui en fait trop et comment la découper sans tomber dans l'excès inverse.