book

La programmation orientée objet

by Hugues Bersini

July 2011

Intermediate to advanced

644 pages

20h 55m

French

Eyrolles

Read now

Unlock full access

L’orientation objet en deux motsObjectifs de l’ouvragePlan de l’ouvrageÀ qui s’adresse ce livre ?
Le trio <entité, attribut, valeur>Stockage des objets en mémoireTypes primitifsLe référent d’un objetPlusieurs référents pour un même objetL’objet dans sa version passiveL’objet et ses constituantsObjet compositeDépendance sans compositionL’objet dans sa version activeActivité des objetsLes différents états d’un objetLes changements d’état : qui en est la cause ?Comment relier les opérations et les attributs ?Introduction à la notion de classeMéthodes et classesSur quel objet précis s’exécute la méthodeDes objets en interactionComment les objets communiquentEnvoi de messagesIdentification des destinataires de messageDes objets soumis à une hiérarchieDu plus général au plus spécifiqueDépendance contextuelle du bon niveau taxonomiquePolymorphismeHéritage bien reçuExercicesExercice 1.1Exercice 1.2Exercice 1.3Exercice 1.4Exercice 1.5
Constitution d’une classe d’objetsDéfinition d’une méthode de la classe : avec ou sans retourIdentification et surcharge des méthodes par leur signatureLa classe comme module fonctionnelDifférenciation des objets par la valeur des attributsLe constructeurMémoire dynamique, mémoire statiqueLa classe comme garante de son bon usageLa classe comme module opérationnelMémoire de la classe et mémoire des objetsMéthodes de la classe et des instancesUn premier petit programme complet dans les cinq langagesEn JavaEN C#En C++En PythonEn PHP 5La classe et la logistique de développementClasses et développement de sous-ensembles logicielsClasses, fichiers et répertoiresExercicesExercice 2.1Exercice 2.2Exercice 2.3Exercice 2.4Exercice 2.5Exercice 2.6Exercice 2.7Exercice 2.8Exercice 2.9
Objectif objet : les aventures de l’OOArgumentation pour l’objetTransition vers l’objetMise en pratiqueSimulation d’un écosystèmeAnalyseAnalyse procéduraleFonctions principalesConceptionConception procéduraleConception objetImpacts de l’orientation objetLes acteurs du scénarioIndépendance de développement et dépendance fonctionnellePetite allusion (anticipée) à l’héritageLa collaboration des classes deux à deux
Envois de messagesAssociation de classesDépendance de classesRéaction en chaîne de messagesExercicesExercice 4.1Exercice 4.2Exercice 4.3Exercice 4.4Exercice 4.5
Pour en finir avec la lutte des classesLa compilation Java : effet dominoEn C#, en Python, PHP 5 et en C++De l’association unidirectionnelle à l’association bidirectionnelleAuto-associationPackage et namespaceExercicesExercice 5.1Exercice 5.2Exercice 5.3Exercice 5.4Exercice 5.5

Passage d’arguments prédéfinis dans les messagesEn JavaEn C#En C++En PythonEn PHP 5Passage d’argument objet dans les messagesEn JavaEn C#En PHP 5En C++En PythonUne méthode est-elle d’office un message ?Même message, plusieurs méthodesInterface : liste de signatures de méthodes disponiblesDes méthodes strictement intimesLa mondialisation des messagesMessage sur InternetL’informatique distribuéeExercicesExercice 6.1Exercice 6.2Exercice 6.3Exercice 6.4Exercice 6.5Exercice 6.6
Accès aux attributs d’un objetAccès externe aux attributsCachez ces attributs que je ne saurais voirEncapsulation des attributsEncapsulation : pourquoi faire ?Pour préserver l’intégrité des objetsLa gestion d’exceptionPour cloisonner leur traitementPour pouvoir faire évoluer leur traitement en douceurLa classe : enceinte de confinementExercicesExercice 7.1Exercice 7.2Exercice 7.3Exercice 7.4
Encapsulation des méthodesInterface et implémentationToujours un souci de stabilitéSignature d’une classe : son interfaceLes niveaux intermédiaires d’encapsulationUne classe dans une autreUtilisation des paquetagesAfin d’éviter l’effet papillonExercicesExercice 8.1Exercice 8.2Exercice 8.3Exercice 8.4Exercice 8.5Exercice 8.6
Question de mémoireUn rappel sur la mémoire RAML’OO coûte cher en mémoireQui se ressemble s’assemble : le principe de localitéLes objets intérimairesMémoire pileDisparaître de la mémoire comme de la vie réelleMémoire tasC++ : le programmeur est le seul maître à bordLa mémoire a des fuitesEn Java, C#, Python et PHP 5 : la chasse au gaspiLe ramasse-miettes (ou garbage collector)Des objets qui se mordent la queueExercicesExercice 9.1Exercice 9.2Exercice 9.3Exercice 9.4Exercice 9.5Exercice 9.6Exercice 9.7Exercice 9.8
Diagrammes UML 2Représentation graphique standardiséeDu tableau noir à l’ordinateurProgrammer par cycles courts en superposant les diagrammesDiagrammes de classe et diagrammes de séquenceDiagramme de classeUne classeSimilitudes et différences entre les langagesAssociation entre classesSimilitudes et différences entre les langagesPas d’association sans messageRôles et cardinalitéDépendance entre classesCompositionEn JavaEn C#En C++En PythonClasse d’associationLes paquetagesLes bienfaits d’UMLUn premier diagramme de classe de l’écosystèmeDes joueurs de football qui font leurs classesLes avantages des diagrammes de classeUn diagramme de classe simple à faire, mais qui décrit une réalité complexe à exécuterProcéder de manière modulaire et incrémentaleDiagramme de séquenceDiagramme d’états-transitionsExercicesExercice 10.1Exercice 10.2Exercice 10.3Exercice 10.4Exercice 10.5Exercice 10.6
Comment regrouper les classes dans des superclassesHéritage des attributsPourquoi l’addition de propriétés ?L’héritage : du cognitif aux taxonomiesInterprétation ensembliste de l’héritageQui peut le plus peut le moinsHéritage ou composition ?Économiser en rajoutant des classes ?Héritage des méthodesLa recherche des méthodes dans la hiérarchieEncapsulation protectedHéritage et constructeursHéritage public en C++Le multihéritageRamifications descendantes et ascendantesMultihéritage en C++ et PythonDes méthodes et attributs portant un même nom dans des superclasses distinctesPlusieurs chemins vers une même superclasseL’héritage virtuelExercicesExercice 11.1Exercice 11.2Exercice 11.3Exercice 11.4Exercice 11.5Exercice 11.6Exercice 11.7Exercice 11.8Exercice 11.9Exercice 11.10Exercice 11.11
La redéfinition des méthodesBeaucoup de verbiage mais peu d’actes véritablesUn match de football polymorphiqueLa classe BallePrécisons la nature des joueursPassons à l’entraîneurPassons maintenant au bouquet finalUn même ordre mais une exécution différentePolymorphisme : uniquement possible dans la mémoire tasQuand la sous-classe doit se démarquer pour marquerLes attaquants participent à un « casting »Éviter les « mauvais castings »Le « casting » a mauvaise presseRedéfinition et encapsulationExercicesExercice 12.1Exercice 12.2Exercice 12.3Exercice 12.4Exercice 12.5Exercice 12.6Exercice 12.7
De Canaletto à TurnerDes classes sans objetDu principe de l’abstraction à l’abstraction syntaxiqueClasse abstraite« new » et « abstract » incompatiblesAbstraite de père en filsUn petit exemple dans les cinq langages de programmationL’abstraction en PythonUn petit supplément de polymorphismeLes enfants de la balleCliquez frénétiquementLe Paris-DakarLe polymorphisme en UMLExercicesExercice 13.1Exercice 13.2Exercice 13.3Exercice 13.4Exercice 13.5Exercice 13.6Exercice 13.7Exercice 13.8Exercice 13.9Exercice 13.10Exercice 13.11Exercice 13.12
Introduction à la classe ObjectUne classe à compétence universelleDécortiquons la classe ObjectTest d’égalité de deux objetsÉgalité en profondeurLe clonage d’objetsÉgalité et clonage d’objets en PythonÉgalité et clonage d’objets en PHP 5Égalité, clonage et affectation d’objets en C++Traitons d’abord la mémoire tasSurcharge de l’opérateur d’affectationComparaisons d’objetsLa mémoire pileSurcharge de l’opérateur de comparaisonDernière étapeEn C#, un cocktail de Java et de C++Pour les structuresPour les classesExercicesExercice 14.1Exercice 14.2Exercice 14.3Exercice 14.4Exercice 14.5Exercice 14.6Exercice 14.7
Interfaces : favoriser la décomposition et la stabilitéJava, C# et PHP 5 : interface via l’héritageLes trois raisons d’être des interfacesForcer la redéfinitionPermettre le multihéritageLa carte de visite de l’objetLes Interfaces dans UML 2En C++ : fichiers .h et fichiers .cppInterfaces : du local à InternetExercicesExercice 15.1Exercice 15.2Exercice 15.3Exercice 15.4Exercice 15.5Exercice 15.6Exercice 15.7Exercice 15.8Exercice 15.9Exercice 15.10
Objets distribués sur le réseau : pourquoi ?Faire d’Internet un ordinateur géantRépartition des donnéesRépartition des utilisateurs et des responsablesPeer-to-peerL’informatique ubiquitaireRobustesseRMI (Remote Method Invocation)Côté serveurCôté clientRMIC : stub et skeletonLancement du registreCorba (Common Object Request Broker Architecture)Un standard : ça compteIDLCompilateur IDL vers JavaCôté clientCôté serveurExécutons l’application CorbaCorba n’est pas polymorphiqueRajoutons un peu de flexibilité à tout celaCorba : invocation dynamique versus invocation statiqueJiniXML : pour une dénomination universelle des servicesLes services web sur .NetCode C# du serviceWDSLCréation du proxyCode C# du clientSoap (Simple Object Access Protocol)Invocation dynamique sous .NetInvocation asynchrone en .NetMais où sont passés les objets ?Un annuaire des services XML universel : UDDIServices web vs RMI et CorbaExercicesExercice 16.1Exercice 16.2Exercice 16.3Exercice 16.4Exercice 16.5Exercice 16.6Exercice 16.7Exercice 16.8Exercice 16.9Exercice 16.10Exercice 16.11Exercice 16.12
Informatique séquentielleMultithreadingImplémentation en JavaImplémentation en C#Implémentation en PythonL’impact du multithreading sur les diagrammes de séquence UMLDu multithreading aux applications distribuéesDes threads équirépartisSynchroniser les threadsExercicesExercice 17.1Exercice 17.2Exercice 17.3Exercice 17.4Exercice 17.5Exercice 17.6Exercice 17.7Exercice 17.8
Des objets qui s’observentEn JavaEn C# : les déléguésGénéralités sur les délégués dans .NetRetour aux observateurs et observablesEn Python : tout reste à faireUn feu de signalisation plus réalisteExercicesExercice 18.1Exercice 18.2Exercice 18.3Exercice 18.4
Sauvegarder l’état entre deux exécutionsEt que dure le disque durQuatre manières d’assurer la persistance des objetsSimple sauvegarde sur fichierUtilisation des « streams »Qui sauve quoi ?Sauvegarder les objets sans les dénaturer : la sérialisationContenu des fichiers de sérialisation : illisibleLes bases de données relationnellesSQLUne table, une classeComment Java et C# s’interfacent aux bases de donnéesRelations entre tables et associations entre classesRelation 1-nRelation n-nDernier problème : l’héritageRéservation de places de spectaclesLes bases de données relationnelles-objetSQL3Les bases de données orientées objetOQLLinqExercicesExercice 19.1Exercice 19.2Exercice 19.3Exercice 19.4Exercice 19.5Exercice 19.6Exercice 19.7Exercice 19.8Exercice 19.9Exercice 19.10
Généralités sur le flipper et les GUIUne petite animation en C#Retour au FlipperUn petit tennis
Le monde regorge de réseauxTout d’abord : juste un ensemble d’objetsListe liéeLa généricité en C++La généricité en Java et C#Passons aux graphesExercicesExercice 21.1Exercice 21.2Exercice 21.3Exercice 21.4Exercice 21.5Exercice 21.6Exercice 21.7Exercice 21.8Exercice 21.9
Pourquoi de la chimie OO ?Chimie computationnelleChimie comme plate-forme didactiqueUne aide à la modélisation chimiqueLes diagrammes de classe du réacteur chimiqueLes composants chimiquesLa classe composant chimiqueLes classes composant neutre et composant chargéLa classe atomeLa classe moléculeLa classe GroupeLes trois sous-classes de composant chargéLa classe NœudAtomiqueLa classe LiaisonLe graphe moléculaireLes règles de canonisationLes réactions chimiquesComment est calculée la cinétique réactionnelleLa classe ReactionLes sous-classes de ReactionQuelques résultats du simulateurLa simulation immunologique en OO ?Petite introduction au fonctionnement du système immunitaireLe diagramme UML d’état-transitionDernière simulation : économie de marché
Introduction aux design patternsDe l’architecte à l’archiprogrammeurLes patterns « truc et ficelle »Le pattern singletonLe pattern adaptateurLes patterns patron de méthode, proxy, observer et mementoLe pattern flyweightLes patterns builder et prototypeLe pattern façadeLes patterns qui se jettent à l’OOLe pattern commandLe pattern décorateurLe pattern compositeLe pattern chain of responsabililtyLes patterns strategy, state et bridge
SymbolesABCDEFGHIJKLMNOPRSTUVWX

Content preview from La programmation orientée objet

Vie et mort des objets

Ce chapitre a pour objectif de présenter les différentes manières d’effacer les objets de la mémoire pendant qu’un programme s’exécute. Nous verrons comment les langages utilisés dans ce livre traitent de ce problème : de la version libérale du C++, confiant la responsabilité au seul programmeur, aux versions plus « marxistes » de Java, Python et PHP 5, laissant un système de régulation centralisé extérieur, appelé ramasse-miettes, s’en occuper, en passant par la troisième voie chère à Tony Blair et proposée par le C#.

Sommaire : Gestion de la mémoire RAM — Dépenses de mémoire inhérentes à l’OO — Mémoire pile et mémoire tas — Le « delete » du C++ — Le ramasse-miettes de Java, C#, PHP 5 et Python

Candidus — Comment ...