Différences

Ci-dessous, les différences entre deux révisions de la page.

--- informatique:design_pattern [19/01/2015 19:13] – [best-practice-software-engineering's Patterns map] cyrille
+++ informatique:design_pattern [03/03/2023 14:56] (Version actuelle) – [Documentation] SOLID principles - Increased maintainability, Increased testability, Increased flexibility, Better code organization cyrille
@@ Ligne 6: / Ligne 6: @@
 Commencer par lire:
-  * [[http://www.crossbowlabs.com/dossiers/principes-avances-oo|Principes avancés de conception objet]].
+  * <del>[[http://www.crossbowlabs.com/dossiers/principes-avances-oo|Principes avancés de conception objet]]</del>.
   * [[http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/|Design Patterns du Gang of Four appliqués à Java]]
   *
@@ Ligne 17: / Ligne 17: @@
   * [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|Les design patterns]] sur le site [[http://best-practice-software-engineering.ifs.tuwien.ac.at|best-practice-software-engineering.ifs.tuwien.ac.at]]
   * [[http://smeric.developpez.com/java/uml/|Tutoriel UML et Design Pattern]] sur [[http://smeric.developpez.com|smeric.developpez.com]]
-  *
+[[https://medium.com/@eloufirhatim/solid-principles-in-laravel-1418be178346|SOLID principles]]
+  * Increased maintainability, Increased testability, Increased flexibility, Better code organization
+  * Single Responsibility Principle (SRP)
+    * The SRP states that a class should have only one reason to change. In other words, a class should only have one responsibility and be focused on doing one thing well.
+  * Open/Closed Principle (OCP)
+    * The OCP states that a class should be open for extension, but closed for modification.
+  * Liskov Substitution Principle (LSP)
+    * The LSP states that objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. In other words, a subclass should be a substitute for its superclass.
+  * Interface Segregation Principle (ISP)
+    * The ISP states that classes should not be forced to implement interfaces they do not use. This principle can be applied by creating smaller, more focused interfaces that define specific tasks
+  * Dependency Inversion Principle (DIP)
+    * The DIP states that high-level modules should not depend on low-level modules, but both should depend on abstractions. This principle helps to reduce the coupling between modules
 ==== best-practice-software-engineering's Patterns map ====