Différences

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

--- java:coo [2020/08/27 11:59] – [Les principes SOLID ou SOIRS] bruno
+++ java:coo [2023/03/23 22:38] (Version actuelle) – bruno
@@ Ligne 8: / Ligne 8: @@
     - une dernière développant l'idée de nommage commun du polymorphisme ad-hoc qui consiste à garantir la substitution d'objets, classiquement en java en utilisant une interface pour déclarer un comportement et en faisant implémenter cette interface par les classes concernées:{{ :java:principes:polym-avance.png?400 |Utilisation d'une interface Reparable avec une méthode reparer, implémentée par Chaise et Autoroute}}
   - **l'héritage** ou la **spécialisation**:  possibilité d'exprimer le fait qu'un concept (une classe) **est un** autre concept (plus exactement **est une** spécialisation d'une abstraction de plus haut niveau) et donc de bénéficier (hériter) de ce qui a été définit dans le concept parent;{{ :java:principes:heritage.png?100 |Le concept Chat est une spécialisation du concept Mammifère, lui même spécialisation de Animal }}
-  - **l'encapsulation**: offrir la possibilité à un programme de n'exposer qu'une partie du code qu'il utilise en masquant le fonctionnement interne d'un objet. Une première manière simple de garantir l'encapsulation est de restreindre la visibilité des attributs en les déclarant **private** et en utilisant des contrôles d'accès **lorsque cela est nécessaire** via les mutateurs (setters) et les accesseurs (getters); plus généralement, **//l'encapsulation ne se limite à la simple utilisation du mot-clef// private**, mais concerne tout ce qui contribue à masquer les fonctionnement interne et protéger les attributs de mutations par des tiers (par exemple, en clonant une référence dans un accesseur, ou en ne donnant pas les types concrets mais des super-types plus abstraits).
+  - **l'encapsulation**: offrir la possibilité à un programme de n'exposer qu'une partie du code qu'il utilise en masquant le fonctionnement interne d'un objet. Une première manière simple de garantir l'encapsulation est de restreindre la visibilité des attributs en les déclarant **private** et en utilisant des contrôles d'accès **lorsque cela est nécessaire** via les mutateurs (setters) et les accesseurs (getters); plus généralement, **//l'encapsulation ne se limite à la simple utilisation du mot-clef// private**, mais concerne tout ce qui contribue à masquer les fonctionnements internes et protéger les attributs de mutations par des tiers (par exemple, en clonant une référence dans un accesseur, ou en ne donnant pas les types concrets mais des super-types plus abstraits).
 ==== En résumé et guise de conclusion ====
@@ Ligne 24: / Ligne 24: @@
 Je présente ici ceux qui font référence aujourd'hui.
-Ces principes s'appuient sur les quatre piliers présentés plus haut, et indique comment les utiliser correctement dans une conception objet.
+Ces principes s'appuient sur les quatre piliers présentés plus haut, et indiquent comment les utiliser correctement dans une conception objet.
 ==== Les principes SOLID ou SOIRS ====
 SOLID est un acronyme proposé par Michael Feathers dans son ouvrage [[https://www.oreilly.com/library/view/working-effectively-with/0131177052/|Working effectively with legacy code]] qui reprend 4 principes compilés par Robert Martin dans son article de 2000 //{{ :java:principes:2000-martin-principles_and_patterns.pdf |Design Principles and Design Patterns}}// et un cinquième de 2002 extrait de Agile Software Development, Principles, Patterns, and Practices (au passage [[https://sites.google.com/site/unclebobconsultingllc/|le site de Martin]] regorge d'informations intéressantes).