Différences

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

--- informatique:design_pattern [05/09/2010 17:46] – 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 ====
@@ Ligne 28: / Ligne 42: @@
     * Delegation
   * Architectural Patterns express a fundamental structural organization or schema for software systems. They provide a set of predefined subsystems, specify their responsibilities, and include rules and guidelines for organizing the relationships between them.
-    * Model View Controller (MVC)
+    * [[#model_view_controller|Model View Controller (MVC)]]
-    * Dependency Injection
+    * [[#dependency_injection|Dependency Injection]]
   * Structural Design Patterns are concerned with how classes and objects are composed together to form larger structures. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
-    * Facade
+    * [[#facade|Facade]]
     * Decorator
     * Proxy
-    * Data Access Object
+    * Data Access Object (DAO)
-    * Transfer Object
+    * [[#data_transfer_object|Data Transfer Object (DTO)]]
   * Creational Design Patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
-    * Factory Method
+    * [[#factoryfabrique|Factory Method]]
-    * Abstract Factory
+    * [[#factoryfabrique|Abstract Factory]]
     * Objectpool
-    * Singleton
+    * [[#singleton|Singleton]]
   * Behavioral Design Patterns are concerned with algorithms and the assignment of responsibilities between objects. [GoF, "Design Patterns", Addison Wesley, ISBN 0201633612]
     * Iterator
-    * Observer
+    * [[#observer|Observer]]
     * Event Listener
-    * Strategy
+    * [[#strategy|Strategy]]
 The diagram below shows the relationships between the patterns described in [[http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns.html|this documentation]], the notation is according to Zimmer's classifications and relationships. [Zimmer, Walter (1995), "Relationships between Design Patterns", from "Pattern Languages of Program Design", Addison-Wesley.]  There are three types of relationships in this diagram: uses (pattern us used by), combine (pattern can be used by), and similar (patterns are similar in their design).