Génie logiciel moderne, livré avec rigueur et IA

Une classe, une raison de changer.

Chaque module ne fait qu'une seule chose — ce qui le rend facile à tester, facile à modifier, et facile à comprendre pour l'ensemble de l'équipe.

// ❌ Too many responsibilities
class UserService {
  save(user: User) { /* DB */ }
  sendWelcomeEmail(user: User) { /* Email */ }
}

// ✅ SRP
class UserRepository { save(user: User) {} }
class EmailService { sendWelcome(user: User) {} }

Ouvert à l'extension, fermé à la modification.

Un système doit pouvoir accueillir de nouveaux comportements sans modifier le code existant — en passant par des abstractions et des interfaces plutôt que des conditions.

interface Exporter { export(data: Data): void; }
class CsvExporter implements Exporter { ... }
class JsonExporter implements Exporter { ... }
// Add a new format = new class, 0 modifications.

Les sous-types doivent respecter le contrat du type parent.

Tout objet d'une sous-classe doit pouvoir remplacer son type parent sans que le comportement du programme ne change — garantissant l'intégrité des hiérarchies d'objets.

class Rectangle { width: number; height: number; }
class Square extends Rectangle {
  // ❌ overriding set width violates Rectangle's contract
}

Plusieurs petites interfaces valent mieux qu'une grande.

Ne forcez pas les implémenteurs à dépendre de méthodes qu'ils n'utilisent pas. Des interfaces ciblées réduisent le couplage et simplifient les tests.

// ❌ Interface too broad
interface Worker { work(): void; eat(): void; }

// ✅ ISP
interface Workable { work(): void; }
interface Feedable { eat(): void; }

Dépendre des abstractions, pas des implémentations.

Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau — les deux doivent dépendre d'abstractions. Fondamental pour la testabilité par injection de dépendances.

// Dependency injection via interface
class OrderService {
  constructor(private readonly repo: OrderRepository) {}
  // repo can be a mock in tests, a real DB in prod
}