Différences

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

--- doc:poo [2018/10/03 22:02] – [SysML] : déplacement root
+++ doc:poo [2020/05/11 00:24] (Version actuelle) – Suppression de la taille par défaut pour les images root
@@ Ligne 3: / Ligne 3: @@
 Une interface est un contrat qui définit un ensemble de méthodes. Les classes qui implémenteront cette interface devront au minimum implémenter ces méthodes.
-{{doc:poo:interface.png?398|Interface}}
+Les interfaces peuvent servirent dans plusieurs cas :
+  * Forcer un groupe de classes à implémenter au minimum certaines méthodes. L'exemple classique est la classe ''Animal'' avec la méthode ''Aller''. Un cheval, il va utiliser 4 pattes, une poule deux, une araignée huit et un poisson va battre de la queue,
+  * Permettre de développer une fonctionnalité utilisant l'interface en attendant qu'une autre personne développe la classe qui respectera l'interface,
+  * Faciliter l'écriture des tests. Si une classe manipule un matériel physique, il peut être difficile de tester une autre classe exploitant le matériel. Il pourra être alors intéressant de remplacer la classe matériel par une fausse classe dite ''mock''.
+  * "Les composants sont visibles des autres composants exclusivement à travers des interfaces".
+{{doc:poo:interface.png|Interface}}
 ====Abstraction====
 Représenter la réalité comme étant un objet.
-En pratique cela consiste à définir des méthodes et des attributs dans une classe. Les méthodes peuvent être déjà implémentées ou alors également laissées abstraites pour forcer le développeur à les implémenter ultérieurement.
+En pratique cela consiste à définir des méthodes dans une classe. Les méthodes peuvent être déjà implémentées ou alors également laissées abstraites pour forcer le développeur à les implémenter ultérieurement.
 ====Encapsulation====
 L'encapsulation regroupe toutes les données et les méthodes implémentées pour les exploiter. Les données peuvent être regroupées dans des ''POJO''/''POCO''/… et invisibles, si besoin, de l'extérieur.
-{{doc:poo:encaps.gif?577|Encapsulation}}
+{{doc:poo:encaps.gif|Encapsulation}}
-[[http://hdd34.developpez.com/cours/artpoo/|Introduction à la Programmation Orientée Objet]], {{ :doc:poo:introduction_a_la_programmation_orientee_objet.mhtml |Archive}}
+[[http://hdd34.developpez.com/cours/artpoo/|Introduction à la Programmation Orientée Objet]] {{ :doc:poo:artpoo.pdf |Archive du 10/09/2011 le 26/04/2020}}
   * Partage de données
-<blockquote>The tempting and straight forward approach for realizing undo is to store the state information directly in the command objects. In many cases this will expose parts of the internal structure of the model and violate the principle of encapsulation.<cite>[[https://dl.acm.org/citation.cfm?doid=1411732.1411738|Source]] {{ :helloworld:design_pattern:command:undomanager:a_framework_for_command_processing_in_javaswing_pr.pdf |Archive}}</cite></blockquote>
+<blockquote>The tempting and straight forward approach for realizing undo is to store the state information directly in the command objects. In many cases this will expose parts of the internal structure of the model and violate the principle of encapsulation.<cite>[[https://dl.acm.org/citation.cfm?doid=1411732.1411738|A framework for command processing in Java/Swing programs based on the MVC pattern]] {{ :helloworld:design_pattern:command:undomanager:a_framework_for_command_processing_in_javaswing_pr.pdf |Archive}}</cite></blockquote>
 ====Héritage====
 L'héritage permet de spécialiser une classe. Il reprend toutes les caractéristiques d'une classe en redéfinissant ou ajoutant des méthodes et en ajoutant des attributs.
-{{doc:poo:poo1.png?350|Héritage}}
+{{doc:poo:poo1.png|Héritage}}
-[[http://www.geek-directeur-technique.com/tag/classe|classe – De geek à directeur technique]], {{ :doc:poo:classe_de_geek_a_directeur_technique.mhtml |Archive}}
+[[https://www.geek-directeur-technique.com/2012/01/10/les-langages-de-programmation-partie-2-le-modele-objet|classe – De geek à directeur technique]] {{ :doc:poo:les_langages_de_programmation_partie_2_le_modele_objet_de_geek_a_directeur_technique_2020-04-26_11_08_19_pm_.html |Archive du 10/01/2012 le 26/04/2020}}
 ====Polymorphisme / redéfinition====
 Le polymorphisme est donc la capacité du système à choisir la méthode qui correspond au type réel de l'objet en cours.
-{{doc:poo:polym.gif?129|}}
+{{doc:poo:polym.gif|}}
-<note important>La méthode appelée variera si sa définition est virtuelle ou non.</note>
+<WRAP center round important 60%>
+La méthode appelée variera si sa définition est virtuelle ou non.
+</WRAP>
 ====Surcharge====
@@ Ligne 41: / Ligne 49: @@
 Exemple : une classe homme est composée avec une classe cœur.
-{{doc:poo:composition.svg.png?400|}}
+{{doc:poo:composition.svg.png|}}
 ====Agrégation====
@@ Ligne 48: / Ligne 56: @@
 Exemple : une classe bibliothèque est agrégé avec une classe livre.
-{{doc:poo:agregation.png?490|Agrégation}}
+{{doc:poo:agregation.png|Agrégation}}
 ====Association====
@@ Ligne 54: / Ligne 62: @@
 Exemple : étudiant et professeur. Même s'il existe dans la réalité une notion de hiérarchie, elle n'a rien à voir dans la notion d'association. Un étudiant peut être dissocié d'un professeur et inversement sans que cela ne pose le moindre problème.
-[[http://javarevisited.blogspot.fr/2014/02/ifference-between-association-vs-composition-vs-aggregation.html|Difference between Association, Composition and Aggregation in Java, UML and Object Oriented Programming]], {{ :doc:poo:difference_between_association_composition_and_aggregation_in_java_uml_and_object_oriented_programming.mhtml |Archive}}
+[[https://javarevisited.blogspot.com/2014/02/ifference-between-association-vs-composition-vs-aggregation.html|Difference between Association, Composition and Aggregation in Java, UML and Object Oriented Programming]] {{ :doc:poo:difference_between_association_composition_and_aggregation_in_java_uml_and_object_oriented_programming_2020-04-26_11_13_44_pm_.html |Archive du 05/02/2017 le 26/04/2020}}