> ## Documentation Index > Fetch the complete documentation index at: https://docs.arkatech.fr/llms.txt > Use this file to discover all available pages before exploring further. # Les grands principes > Le but de ces principes est de produire du code qui soit facile à comprendre, à modifier et à tester, minimisant ainsi le risque d'introduire des bugs. # Principes de Conception SOLID (POO) Les principes **SOLID** sont un ensemble de cinq concepts directeurs pour la conception de classes et de modules dans les langages de Programmation Orientée Objet (POO). Leur application vise à rendre le logiciel plus compréhensible, flexible et maintenable. | **Principe** | **Nom Complet** | **Description** | **Bonne Pratique (À Faire)** | **Erreur à Éviter (Anti-Pattern)** | | :----------- | :---------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | | **S** | **Single Responsibility Principle (SRP)** | Une classe ou un module doit avoir **une seule et unique raison** d'être modifié. | Si un changement de la DB et un changement de la logique de calcul affectent la même classe, divisez cette classe. | Créer des classes "God Objects" (objets divins) qui gèrent des dizaines de responsabilités différentes. | | **O** | **Open/Closed Principle (OCP)** | Les entités logicielles (classes, modules) doivent être **ouvertes à l'extension**, mais **fermées à la modification**. | Utiliser l'héritage ou l'injection de dépendances pour ajouter de nouvelles fonctionnalités sans toucher au code existant et testé. | Modifier directement les classes de base et forcer la re-validation de tout code dépendant. | | **L** | **Liskov Substitution Principle (LSP)** | Les objets d'un programme doivent pouvoir être remplacés par des instances de leurs sous-types sans altérer la justesse du programme. | Assurez-vous que les classes dérivées respectent le contrat de la classe de base (les méthodes héritées ne doivent pas casser la logique attendue). | Créer une sous-classe dont les méthodes lèvent des exceptions inattendues ou ne font rien lorsque l'on attend une action. | | **I** | **Interface Segregation Principle (ISP)** | Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas. | Créer des interfaces petites et spécifiques (interfaces granulaires) plutôt qu'une seule interface massive. | Définir une interface `Monolithe` avec 20 méthodes, forçant toutes les classes à implémenter des méthodes dont elles n'ont pas besoin. | | **D** | **Dependency Inversion Principle (DIP)** | Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Tous deux devraient dépendre d'abstractions (interfaces). | Utiliser l'**Injection de Dépendances** (DI) pour lier les abstractions aux implémentations au moment de l'exécution. | Lier directement la logique métier (haut niveau) à une implémentation concrète (ex: un driver de DB spécifique), rendant le remplacement impossible. | # Principes de Conception Généraux En complément de SOLID, ces principes visent à améliorer la simplicité, la clarté et l'efficacité générale du code. | **Principe** | **Nom Complet** | **Description** | **Bonne Pratique (À Faire)** | **Erreur à Éviter (Anti-Pattern)** | | :----------- | :-------------------------- | :------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------- | | **KISS** | **Keep It Simple, Stupid** | Choisir la solution la plus simple et la plus directe possible pour résoudre un problème. | Écrire du code simple, clair, même s'il est légèrement plus long que l'alternative ultra-optimisée. | Sur-concevoir une solution simple en utilisant des patrons de conception complexes (ex: utiliser un système de Message Queue pour un simple appel local). | | **DRY** | **Don't Repeat Yourself** | Toute connaissance dans un système doit avoir une représentation unique, non ambiguë, faisant autorité. | Factoriser la logique métier en fonctions ou méthodes réutilisables. Utiliser des *Hooks* ou des *Mixins*. | Copier-coller des blocs de code similaires à plusieurs endroits. Si la logique change, il faut la modifier partout. | | **YAGNI** | **You Ain't Gonna Need It** | Ne pas ajouter de fonctionnalités ou de code tant qu'il n'est pas absolument nécessaire. | Se concentrer sur les exigences actuelles et la livraison de valeur immédiate. | Développer des fonctionnalités "au cas où" (Over-engineering), ce qui augmente la dette technique et le temps de développement. | # Clean Code (Code Propre) Le concept de "Clean Code", popularisé par Robert C. Martin (Uncle Bob), se concentre sur la lisibilité et la maintenance du code par les humains. **Bonnes Pratiques Clés** * **Nommage Significatif :** * **À Faire :** Utiliser des noms complets et sans ambiguïté. Ex: `clientRepository.fetchActiveUsers()`. * **À Éviter :** Abréviations ou noms à un caractère. Ex: `cl.getA()`. * **Fonctions et Méthodes Courtes :** * **À Faire :** Les fonctions ne doivent faire **qu'une seule chose** et le faire bien (lié au SRP). Idéalement, elles ne devraient pas dépasser 20 lignes. * **À Éviter :** Fonctions "Monstres" de plusieurs centaines de lignes qui gèrent le flux, le formatage, et la communication externe. * **Commentaires :** * **À Faire :** Utiliser les commentaires pour expliquer le *pourquoi* (les décisions complexes, les contraintes métier non évidentes). * **À Éviter :** Utiliser les commentaires pour expliquer le *quoi* ou le *comment* (ce que le code fait, ce qui devrait être évident si le code est bien écrit). Ex: `// Incrémente i` à côté de `i++`. * **Tests Unitaires :** Le code est considéré comme "propre" s'il est testable. Si une classe ou une fonction est difficile à tester unitairement, c'est souvent le signe d'une mauvaise conception (violation de SRP/DIP).