0% ont trouvé ce document utile (0 vote)
52 vues53 pages

Support POO 2024

Ce document présente un cours sur la programmation orientée objet (POO), abordant ses concepts fondamentaux, les langages associés, ainsi que des outils de modélisation comme UML. Il couvre également des notions avancées telles que la gestion des erreurs, les interfaces, et les design patterns. L'objectif est de fournir aux étudiants une compréhension approfondie de la POO à travers des exemples pratiques et des exercices.

Transféré par

thierryikm
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOC, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
52 vues53 pages

Support POO 2024

Ce document présente un cours sur la programmation orientée objet (POO), abordant ses concepts fondamentaux, les langages associés, ainsi que des outils de modélisation comme UML. Il couvre également des notions avancées telles que la gestion des erreurs, les interfaces, et les design patterns. L'objectif est de fournir aux étudiants une compréhension approfondie de la POO à travers des exemples pratiques et des exercices.

Transféré par

thierryikm
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOC, PDF, TXT ou lisez en ligne sur Scribd

INITIATION À LA PROGRAMMATION

ORIENTÉE OBJET


Thierry ILUNGA
Ir. Informaticien

2024
PLAN DU COURS

PLAN DU COURS
0. INTRODUCTION.
0.1. Objectif
0.2. Pré requis
CHAPITRE.I. GENERALITES.
I.1 Les langages de programmation.
I.1.1 Définition
I.1.2 Utilisation
I.1.3 Notions courantes
I.1.4 Paradigmes
I.1.5 Mise en œuvre
I.2 Origines de la POO.
I.3 Objectifs de la POO
I.4 Les langages Orientés Objet.
CHAPITRE.II. CONCEPTS FONDAMENTAUX.
II.1 Objets
II.2 Classe
II.3 Encapsulation
II.4 Héritage
II.5 Polymorphisme
CHAPITRE.III. UML (Unified Modeling Language)
III.1 Introduction à UML.
III.2 Diagrammes de classes
III.2.1 Éléments d'un diagramme de classes.
III.2.2 Exemple de diagramme de classes.
III.3 Diagramme de cas d’utilisation.
III.3.1 Éléments du diagramme de cas d'utilisation
III.3.2 Exemple de diagramme de cas d'utilisation.
III.4 Diagrammes de séquence.
III.4.1 Éléments d'un diagramme de séquence.
III.4.2 Exemple de diagramme de séquence
III.5 Exercices pratiques de modélisation UML
III.5.1 Exercice 1 : Diagramme de classes
III.5.2 Exercice 2 : Diagramme de séquence
III.5.3 Exercice 3 : Diagramme de cas d’utilisation.

2
CHAPITRE.IV. Concepts Avancés en Programmation
Orientée Objet.
IV.1 Exceptions et Gestion des Erreurs
IV.1.1 Concept des exceptions
IV.1.2 Gestion des exceptions
IV.2 Interfaces et Classes Abstraites
IV.2.1 Définition et utilisation des interfaces
IV.2.2 Implémentation d'interfaces
IV.2.3 Classes abstraites vs interfaces
IV.3 Collections et Structures de Données
IV.3.1 Introduction aux collections
IV.3.2 Utilisation des collections dans la POO
CHAPITRE.V. Design Patterns
V.1 Introduction aux Design Patterns
V.1.1 . Patterns de Création
V.1.2 . Patterns de Structure
V.1.3 . Patterns de Comportement
CONCLUSION
BIBLIOGRAPHIE
TABLES DES MATIERES
ANNEXES.

2
0. INTRODUCTION.

La programmation de logiciels a connu il y a quelques


années le passage d'une ère artisanale à une ère
industrielle. Des logiciels de plus en plus complexes
doivent être réalisés dans des délais de plus en plus
courts, tout en maintenant le meilleur niveau de
qualité possible.

Comment faire pour répondre à ces exigences


contradictoires ? La solution passe par l'emploi de
techniques de développement adaptées.

La programmation orientée objet, souvent abrégée


POO, permet de concevoir une application sous la
forme d'un ensemble de briques logicielles appelées
des objets. Chaque objet joue un rôle précis et peut
communiquer avec les autres objets. Les interactions
entre les différents objets vont permettre à
l'application de réaliser les fonctionnalités attendues.

La POO facilite la conception de programmes par


réutilisation de composants existants, avec tous les
avantages évoqués plus haut. Elle constitue le
standard actuel (on parle de paradigme) en matière
de développement de logiciels.

0.1. Objectif
Ce cours vise à donner à l’étudiant un aperçu sur la
programmation orientée objets avec l’utilisation de
JAVA.

0.2. Pré requis


Ce cours nécessite une connaissance des bases de la
programmation : Notions de variable et de type,
structures conditionnelles et itératives (boucles),

2
programmation modulaire (sous-programmes) et
passage de paramètres, tableaux et listes.

2
CHAPITRE.I. GENERALITES.

I.1 Les langages de programmation.

Un langage de programmation est une notation


conventionnelle destinée à formuler des algorithmes
et produire des programmes informatiques qui les
appliquent. D'une manière similaire à une langue
naturelle, un langage de programmation est composé
d'un alphabet, d'un vocabulaire, de règles de
grammaire, de significations, mais aussi d'un
environnement de traduction censé rendre sa syntaxe
compréhensible par la machine.

Les langages de programmation permettent de décrire


d'une part les structures des données qui seront
manipulées par l'appareil informatique, et d'autre part
d'indiquer comment sont effectuées les manipulations,
selon quels algorithmes. Ils servent de moyens de
communication par lesquels le programmeur
communique avec l'ordinateur, mais aussi avec
d'autres programmeurs ; les programmes étant
d'ordinaire écrits, lus, compris et modifiés par une
équipe de programmeurs.

Un langage de programmation est mis en œuvre par


un traducteur automatique : compilateur ou
interpréteur. Un compilateur est un programme
informatique qui transforme dans un premier temps
un code source écrit dans un langage de
programmation donné en un code cible qui pourra
être directement exécuté par un ordinateur, à savoir
un programme en langage machine ou en code
intermédiaire, tandis que l’interpréteur réalise cette
traduction « à la volée ».

2
Chaque langage de programmation supporte une ou
plusieurs approches de la programmation –
paradigmes.

Les premiers langages de programmation ont été


créés dans les années 1950 en même temps que
l'avènement des ordinateurs. Cependant, de
nombreux concepts de programmation ont été initiés
par un langage ou parfois plusieurs langages, avant
d'être améliorés puis étendus dans les langages
suivants. La plupart du temps la conception d'un
langage de programmation a été fortement influencée
par l'expérience acquise avec les langages
précédents.

I.1.1 Définition

Un langage de programmation est construit à partir


d'une grammaire formelle, qui inclut des symboles et
des règles syntaxiques, auxquels on associe des
règles sémantiques. Ces éléments sont plus ou moins
complexes selon la capacité du langage.

a. Les règles de syntaxe

Définies par une grammaire formelle, elles régissent


les différentes manières dont les éléments du langage
peuvent être combinés pour obtenir des programmes.
La ponctuation (par exemple l'apposition d'un symbole
; en fin de ligne d'instruction d'un programme) relève
de la syntaxe.

b. Le vocabulaire

Parmi les éléments du langage, le vocabulaire


représente l'ensemble des instructions construites
d’après des symboles. L'instruction peut être
mnémotechnique ou uniquement symbolique comme

2
quand elle est représentée par des symboles
d'opérations tels que des opérateurs arithmétiques («
+ » et « - ») ou booléens (&& pour le et logique par
exemple). On parle aussi parfois de mot clé pour
désigner une instruction (par abus de langage car le
concept de mot clé ne recouvre pas celui des
symboles qui font pourtant eux aussi partie du
vocabulaire).

c. La sémantique

Les règles de sémantique définissent le sens de


chacune des phrases qui peuvent être construites
dans le langage, en particulier quels seront les effets
de la phrase lors de l'exécution du programme.

d. L’alphabet

L'alphabet des langages de programmation est basé


sur les normes courantes comme ASCII, qui comporte
les lettres de A à Z sans accent, des chiffres et des
symboles, ou Unicode pour la plupart des langages
modernes (dans lesquels l'utilisation se limite en
général aux chaînes de caractères littérales et aux
commentaires, avec quelques exceptions notables
comme C♯ qui autorisent également les identifiants
unicode).

e. Les commentaires

Les commentaires sont des textes qui ne seront pas


traduits. Ils peuvent être ajoutés dans les programmes
pour y laisser des explications. Les commentaires sont
délimités par des marques qui diffèrent d'un langage
de programmation à l'autre tel que « -- », « /* » ou « //
».

f. Les identifiants

2
Les éléments constitutifs du programme, tels que les
variables, les procédures ou les types servent à
organiser le programme et son fonctionnement. On
peut ainsi, par exemple, diviser un programme en
fonctions ou lui donner une structure par objets : ces
éléments de structure sont définis par des identifiants
ou des procédures par mot clé selon le langage.

I.1.2 Utilisation

Un langage de programmation offre un cadre pour


élaborer des algorithmes et exprimer des diagrammes
de flux. Il permet en particulier de décrire les
structures des données qui seront manipulées par
l'appareil informatique et quelles seront les
manipulations. Un langage de programmation sert de
moyen de communication avec l'ordinateur mais aussi
entre programmeurs : les programmes étant
d'ordinaire écrits, lus et modifiés par une équipe de
programmeurs.

Les programmeurs apprécient qu'un langage de


programmation soit en ligne avec les bonnes
pratiques de programmation et d'ingénierie, qu'il
encourage la structuration du programme, facilite la
maintenance des programmes et qu'il dissuade, voire
interdise les mauvaises pratiques. L'utilisation de
l'instruction goto, par exemple, qui existe depuis les
premiers langages de programmation, est considérée
comme une mauvaise pratique. Son utilisation est
déconseillée, voire impossible dans les langages de
programmation récents.

I.1.3 Notions courantes

Un langage de programmation repose sur un


ensemble de notions telles que les instructions, les
variables, les types et les procédures ou fonctions, qui

2
peuvent être utilisées comme primitives pour
développer des algorithmes.

a. Une instruction
Un ordre donné à un ordinateur.

b. Une variable
Un nom utilisé dans un programme pour faire
référence à une donnée manipulée par programme.

c. Une constante
Un nom utilisé pour faire référence à une valeur
permanente.

d. Une expression littérale


Une valeur mentionnée en toutes lettres dans le
programme.

e. Un type
Chaque donnée a une classification, celle-ci influe sur
la plage de valeurs possibles, les opérations qui
peuvent être effectuées et la représentation de la
donnée sous forme de bits. Chaque langage de
programmation offre une gamme de types primitifs,
incorporés dans le langage. Certains langages offrent
la possibilité de créer des nouveaux types.

Les types de données primitifs courants sont les


nombres entiers, les nombres réels, le booléen, les
chaînes de caractères et les pointeurs.

f. Une structure de données


Une manière caractéristique d'organiser un ensemble
de données en mémoire, qui influe sur les algorithmes
utilisés pour les manipuler. Les structures courantes

2
sont les tableaux, les enregistrements, les listes, les
piles, les files et les arbres.

g. Une déclaration
Une phrase de programme qui sert à renseigner au
traducteur (compilateur, interpréteur...) les noms et
les caractéristiques des éléments du programme tels
que des variables, des procédures, de types, etc.

h. Les procédures, fonctions, méthodes


Divers langages de programmation offrent la
possibilité d'isoler un fragment de programme et d'en
faire une opération générale, paramétrable,
susceptible d'être utilisée de façon répétée. Ces
fragments sont appelés procédures, fonctions ou
méthodes, selon le paradigme.

i. Les modules
Les langages de programmation peuvent également
offrir la possibilité de découper un programme en
plusieurs pièces appelées modules, chacune ayant un
rôle déterminé, puis de combiner les pièces.

I.1.4 Paradigmes

Un paradigme est une façon d'approcher la


programmation. Chaque paradigme amène sa
philosophie de la programmation ; une fois qu'une
solution a été imaginée par un programmeur selon un
certain paradigme, un langage de programmation qui
suit ce paradigme permettra de l'exprimer.

Impératif, déclaratif, fonctionnel, logique, orienté


objet, concurrent, visuel, événementiel et basé web
sont des paradigmes de programmation. Chaque

2
langage de programmation reflète un ou plusieurs
paradigmes, apportant un ensemble de notions qui
peuvent être utilisées pour exprimer une solution à un
problème de programmation.

Au cours de l'histoire, les scientifiques et les


programmeurs ont identifié les avantages et les
limitations d'un style de programmation et apporté de
nouveaux styles. La plupart des langages de
programmation contemporains permettent d'adopter
plusieurs paradigmes de programmation à condition
que ceux-ci soient compatibles.

1. Impératif (ou procédural)


Le paradigme impératif ou procédural est basé sur le
principe de l'exécution étape par étape des
instructions tout comme on réalise une recette de
cuisine. Il est basé sur le principe de la machine de
Von Neumann15. Un ensemble d'instructions de
contrôle de flux d'exécution permet de contrôler
l'ordre dans lequel sont exécutées les instructions qui
décrivent les étapes. Le C, le Pascal, le Fortran et le
COBOL sont des exemples de langage de
programmation qui implémentent le paradigme
impératif14.

2. Déclaratif
Il y a essentiellement deux paradigmes déclaratifs ; ce
sont le paradigme fonctionnel et le paradigme logique.
En paradigme fonctionnel, le programme décrit des
fonctions mathématiques. En paradigme logique, il
décrit des prédicats : c'est-à-dire des déclarations qui,
une fois instanciées, peuvent être vraies ou fausses ou
ne pas recevoir de valeur de vérité (quand l'évaluation
du prédicat ne se termine pas)13. Dans un modèle
d'implantation, une machine abstraite effectue les
opérations nécessaires pour calculer le résultat de
chaque fonction16 ou chaque prédicat. Dans ces

2
paradigmes, une variable n'est pas modifiée par
affectation13. Une des caractéristiques principales17
est la transparence référentielle, qui fait qu'une
expression peut être remplacée par son résultat sans
changer le comportement du programme.

3. Fonctionnel
Le paradigme fonctionnel a pour principe l'évaluation
de formules, afin d'utiliser le résultat pour d'autres
calculs ; il s'appuie sur la récursivité et il a pour
modèle le lambda-calcul, plus précisément la
réduction en forme normale de tête. Tous les calculs
évaluent des expressions ou font appel à des
fonctions. Pour simplifier18, le résultat d'un calcul sert
pour le calcul ou les calculs qui ont besoin de son
résultat jusqu'à ce que la fonction qui produit le
résultat du programme ait été évaluée14. Le
paradigme fonctionnel a été introduit par les langages
Lisp et ISWIM ainsi qu'en ce qui concerne les fonctions
récursives par Algol 60, dans les années 1960. Des
langages tels que Ruby et Scala supportent plusieurs
paradigmes dont le paradigme fonctionnel13, tandis
qu'Haskell ne supporte que le paradigme fonctionnel
et OCaml privilégie le paradigme fonctionnel qu'il
partage avec le paradigme objet et une petite dose
d'impératif.

4. Logique
Le paradigme logique vise à répondre à une question
par des recherches dans un ensemble, en utilisant des
axiomes, des requêtes et des règles de déduction.
L'exécution d'un programme est une cascade de
recherches de faits dans un ensemble, en invoquant
des règles de déduction. Les données obtenues,
peuvent être associées à un autre ensemble de règles
et peuvent alors être utilisées dans le cadre d'une
autre recherche. L'exécution du programme se fait par
évaluation : le système effectue une recherche de
toutes les affirmations qui, par déduction,

2
correspondent à au moins un élément de l'ensemble.
Le programmeur exprime les règles, et le système
pilote le processus. Le paradigme logique a été
introduit par le langage Prolog en 1970.

5. Orienté objet
Le paradigme orienté objet est destiné à faciliter le
découpage d'un grand programme en plusieurs
modules isolés les uns des autres. Il introduit les
notions d'objet et d'héritage. Un objet contient les
variables et les fonctions en rapport avec un sujet. Les
variables peuvent être privées, c'est-à-dire qu'elles
peuvent être manipulées uniquement par l'objet qui
les contient. Un objet contient implicitement les
variables et les fonctions de ses ancêtres, et cet
héritage aide à réutiliser du code13. Le paradigme
orienté objet permet d'associer fortement les données
avec les procédures14. Il a été introduit par le langage
Simula dans les années 1960 et est devenu populaire
dans les années 1980, quand l'augmentation de la
puissance de calcul des ordinateurs a permis
d'exécuter des grands programmes13. Divers
langages de programmation ont été enrichis en vue
de permettre la programmation orientée objet ; c'est
le cas de C++ (dérivé du langage C13), Simula,
Smalltalk, Swift et Java sont des langages de
programmation en paradigme orienté objet.

6. Concurrent
En paradigme concurrent un programme peut
effectuer plusieurs tâches en même temps. Ce
paradigme introduit les notions de thread, d'attente
active et d'appel de fonction à distance13. Ces notions
ont été introduites dans les années 1980 lorsque, à la
suite de l'évolution technologique, un ordinateur est
devenu une machine comportant plusieurs
processeurs et capable d'effectuer plusieurs tâches
simultanément. Les langages de programmation

2
contemporains de 2013 tels que C++ et Java sont
adaptés aux microprocesseurs multi-cœur et
permettent de créer et manipuler des threads. Plus
récemment, on a vu apparaître des langages
intégralement orientés vers la gestion de la
concurrence, comme le langage Go.

7. Visuel
Dans la grande majorité des langages de
programmation, le code source est un texte, ce qui
rend difficile l'expression des objets bidimensionnels.
Un langage de programmation tel que Delphi ou C#
permet de manipuler des objets par glisser-déposer et
le dessin ainsi obtenu est ensuite traduit en une
représentation textuelle orientée objet et
événementielle. Le paradigme visuel a été introduit à
la fin des années 1980 par Alan Kay dans le langage
Smalltalk, dans le but de faciliter la programmation
des interfaces graphiques.

8. Événementiel
Alors qu'un programme interactif pose une question et
effectue des actions en fonction de la réponse, en
style événementiel le programme n'attend rien et est
exécuté lorsque quelque chose s'est passé. Par
exemple, l'utilisateur déplace la souris ou presse sur
un bouton. Dans ce paradigme, la programmation
consiste à décrire les actions à prendre en réponse
aux événements. Et une action peut en cascade
déclencher une autre action correspondant à un autre
événement. Le paradigme événementiel a été
introduit par le langage Simula dans les années 1970.
Il est devenu populaire à la suite de l'avènement des
interfaces graphiques et des applications web.

9. Basé web
Avec l’avènement de l'Internet dans les années 1990,
les données, les images ainsi que le code s'échangent
entre ordinateurs. Si un résultat est demandé à un

2
ordinateur, celui-ci peut exécuter le programme
nécessaire et envoyer le résultat. Il peut également
envoyer le code nécessaire à l'ordinateur client pour
qu'il calcule le résultat lui-même13. Le programme est
rarement traduit en langage machine, mais plutôt
interprété ou traduit en une forme intermédiaire, le
bytecode, qui sera exécuté par une machine virtuelle,
ou traduit en langage machine au moment de
l'exécution (just-in-time). Java, PHP et Javascript sont
des langages de programmation basée web.

I.1.5 Mise en œuvre


L'utilisation d'un langage est rendue possible par un
traducteur automatique. Un programme qui prend un
texte écrit dans ce langage pour en faire quelque
chose, en général soit :

 Un compilateur
Un programme qui traduit le texte dans un langage
qui permettra son exécution, tel le langage machine,
le bytecode ou le langage assembleur.

 Un interpréteur
Un programme qui exécute les instructions
demandées. Il joue le même rôle qu'une machine qui
reconnaîtrait ce langage.

a. Langage machine

Chaque appareil informatique a un ensemble


d'instructions qui peuvent être utilisées pour effectuer
des opérations. Les instructions permettent
d'effectuer des calculs arithmétiques ou logiques,
déplacer ou copier des données, ou bifurquer vers
l'exécution d'autres instructions. Ces instructions sont
enregistrées sous forme de séquences de bits, où
chaque séquence correspond au code de l'opération à

2
effectuer et aux opérandes, c'est-à-dire aux données
concernées ; c'est le langage machine.

La traduction s'effectue en plusieurs étapes. En


premier lieu, le traducteur effectue une analyse
lexicale où il identifie les éléments du langage utilisés
dans le programme. Dans l'étape suivante, l'analyse
syntaxique, le traducteur construit un diagramme en
arbre qui reflète la manière dont les éléments du
langage ont été combinés dans le programme, pour
former des instructions. Puis, lors de l'analyse
sémantique, le traducteur détermine s'il est possible
de réaliser l'opération et les instructions qui seront
nécessaires dans le langage cible.

b. L’assembleur

Dans le langage de programmation assembleur, des


mots aide-mémoire (mnémonique) sont utilisés pour
référer aux instructions de la machine. Les
instructions diffèrent en fonction des constructeurs et
il en va de même pour les mnémoniques. Un
programme assembleur traduit chaque mnémonique
en la séquence de bits correspondante.

c. Un runtime

Les langages de programmation fonctionnent souvent


à l'aide d'un runtime.

Un runtime (traduction : exécuteur) est un ensemble


de bibliothèques logicielles qui mettent en œuvre le
langage de programmation, permettant d'effectuer
des opérations simples, telles que copier des données,
mais aussi des opérations beaucoup plus complexes.

Lors de la traduction d'un programme vers le langage


machine, les opérations simples sont traduites en
instructions correspondantes en langage machine

2
tandis que les opérations complexes sont traduites en
des utilisations des fonctions du runtime. Dans
certains langages de programmation, la totalité des
instructions sont traduites en des utilisations du
runtime qui sert alors d'intermédiaire entre les
possibilités offertes par la plateforme informatique et
les constructions propres au langage de
programmation.

I.2 Origines de la POO.

Les différentes étapes sont les suivantes :

A. Début des années 60 : langages de bas niveau


 Assembleur
 Programmes difficiles à réaliser
 Temps de conception difficile à estimer
 Peu de méthode pour la conception
B. Fin des années 60 : langages de plus haut niveau
 Fortran, Cobol
 Apparition du concept de cycle de vie des
logiciels
C. Années 70 : Programmation structurée
 Pascal, C
 Apparition du concept fondamental
d’abstraction
 Structuration des données
 Procédures et fonctions
 Librairie de fonctions
Naissance des concepts d’abstraction et de
réutilisation.
D. Années 80 : langages orientés-objets
 Smalltalk, C++

I.3 Objectifs de la POO

- Gagner en productivité et abaisser les couts

2
- Augmenter la qualité des logiciels et leurs
fonctionnalités
- Faciliter la maintenance et l’évolution des
applications

Comment y arriver ?

 Par un processus de développement plus rapide


et plus rigoureux ;
 Grace à une réutilisation des développements.

 Bref une Industrialisation du processus de


production

I.4 Les langages Orientés Objet.

Il y a plus ou moins 20 langages actuellement mais 3


langages OO dominent :

 C++

2
 Smalltalk
 Java

 C++
 Avantages :
 Syntaxe proche du langage C
 Compatibilité avec le langage C
 Programmes rapides et efficaces

 Inconvénients :
 Syntaxe trop proche du langage C
 Utilise le compile-time binding
 Allocation et désallocation explicite de la
mémoire
 Utilise les pointeurs

 Smalltalk
 Avantages :
 Syntaxe simple
 Langage OO pur
 Utilise le run-time binding
 Code généré portable : byte code
 Programmes plus rapides à développer
 Pas d’allocation et désallocation
explicite de la mémoire
 Inconvénients :
 Maitrise assez difficile
 Programmes nécessitants plus de
ressources systèmes

 Java

 Avantages :
 Utilise le run-time binding
 Syntaxe proche du C/C++
 Pas de pointeurs
 Pas d’allocation et désallocation
explicite de la mémoire
 Code généré portable : byte code

2
 Inconvénients :
 Programmes nécessitants plus de
ressources systèmes

CHAPITRE.II. CONCEPTS FONDAMENTAUX.

II.1 Objets
Un objet est une entité manipulée par le langage,
caractérisé par :

 Une Identité
 Un Etat Interne
 Un Comportement

Exemple de modélisation d’objet


Représentation d’une personne par un objet
 Une Identité
Existence concrète des objets de type
« personnes »

 Un Etat Interne
Attribut : Nom, Sexe, Date de naissance, taille

 Un Comportement
Donner son nom
Donner son sexe
Donner son âge
Donner sa taille

Interaction avec un objet

2
Interagir avec un objet c’est lui demander d’effectuer
une opération en lui envoyant un message
Exemple
Interaction avec un objet « personne » par le biais de
messages correspondant aux requêtes :

Quel est votre nom ?


Quel est votre sexe ?
Quel est votre âge ?
Quel est votre taille ?

II.2 Classe

Une classe regroupe une famille d’objets dont les


caractéristiques sont les mêmes.

Exemple de la classe « personne »

Caractéristiques des objets :


 Même structures : même attributs
 Valeurs des attributs différentes
 Même manière de répondre a un message
quel qu’il soit
La création d’un objet à partir d’une classe s’appelle :
l’instanciation.

2
II.3 Encapsulation
L’encapsulation désigne le principe de regrouper des
données avec un ensemble de routines permettant de
lire lesdites données ou de les manipuler. Ce principe
est souvent accompagné du masquage de ces
données brutes afin de s’assurer que l’utilisateur ne
contourne pas l’interface qui lui est destinée.

L’encapsulation peut être représentée le niveau de


visibilité que peut avoir un objet vis-à-vis d’un autre.
L’encapsulation des données présente un intérêt
manifeste en matière de qualité de logiciel. Elle facilite
considérablement la maintenance : une modification
éventuelle de la structure des données d’un objet n’a
d’incidence que sur l’objet lui-même ; les utilisateurs
de l’objet ne seront pas concernés par la teneur de
cette modification (ce qui n’était bien sûr pas le cas

2
avec la programmation structurée). De la même
manière, l’encapsulation des données facilite
grandement la réutilisation d’un objet.

II.4 Héritage
Un autre concept important en P.O.O. est celui
d’héritage. Il permet de définir une nouvelle classe à
partir d’une classe existante (qu’on réutilise en bloc !),
à laquelle on ajoute de nouvelles données et de
nouvelles méthodes. La conception de la nouvelle
classe, qui hérite des propriétés et des aptitudes de
l’ancienne, peut ainsi s’appuyer sur des réalisations
antérieures parfaitement au point et les spécialiser à
volonté. Comme on peut s’en douter, l’héritage facilite
largement la réutilisation de produits existants,
d’autant plus qu’il peut être réitéré autant de fois que
nécessaire (la classe C peut hériter de B, qui elle-
même hérite de A).

II.5 Polymorphisme
En Java, comme généralement, en P.O.O., une classe
peut "redéfinir" (c’est-à-dire modifier) certaines des
méthodes héritées de sa classe de base. Cette
possibilité est la clé de ce que l’on nomme le
"polymorphisme », c’est-à-dire la possibilité de traiter
de la même manière des objets de types différents,
pour peu qu’ils soient issus de classes dérivées d’une
même classe de base.

Plus précisément, on utilise chaque objet comme s’il


était de cette classe de base, mais son comportement
effectif dépend de sa classe effective (dérivée de cette
classe de base), en particulier de la manière dont ses
propres méthodes ont été redéfinies. Le
polymorphisme permet d’ajouter de nouveaux objets
dans un scénario préétabli et, éventuellement, écrit

2
avant d’avoir connaissance du type exact de ces
objets.

CHAPITRE.III. UML (Unified Modeling


Language)

III.1 Introduction à UML.

UML, ou Unified Modeling Language, est un langage


de modélisation standardisé utilisé pour visualiser,
spécifier, construire et documenter les artefacts d'un
système logiciel.

UML a été développé par l'Object Management Group


(OMG) et est largement utilisé dans l'industrie du
logiciel pour la conception et la documentation des
systèmes.

2
UML fournit un ensemble de diagrammes qui
permettent de représenter différents aspects d'un
système logiciel, tels que la structure statique, le
comportement dynamique, et les interactions entre
les composants. Les diagrammes UML sont utilisés
pour communiquer les idées de conception entre les
membres de l'équipe de développement, les parties
prenantes, et les clients.

UML est un langage de modélisation utilisé en


développement logiciel pour représenter visuellement
les systèmes informatiques. Il aide à comprendre,
concevoir et documenter les applications avant de les
programmer.

Pourquoi utiliser UML ?

1. Visualiser : UML permet de voir la structure et


le fonctionnement d'un logiciel.
2. Concevoir : Il aide à planifier le système avant
de coder.
3. Communiquer : Il facilite la compréhension
entre les membres d'une équipe.
4. Documenter : Les diagrammes servent de
référence tout au long du projet.

Il existe 14 diagrammes UML selon leur catégorie


dans la version UML 2.x :

1. Diagrammes structurels (6 diagrammes)

But : Décrire l'aspect statique du système, ses


composants et leurs relations :
1. Diagramme de classes (Class Diagram)
o Montre les classes, leurs attributs,
méthodes et relations.
2. Diagramme d'objets (Object Diagram)

2
o Représente un instantané des objets et
leurs relations à un moment donné.
3. Diagramme de composants (Component
Diagram)
o Montre les composants logiciels et leurs
dépendances.
4. Diagramme de déploiement (Deployment
Diagram)
o Représente l'architecture matérielle et
logicielle, ainsi que le déploiement des
composants.
5. Diagramme de packages (Package
Diagram)
o Organise les éléments du système en
packages pour plus de clarté.
6. Diagramme de structure composite
(Composite Structure Diagram)
o Décrit l'agencement interne d'un
système, d'une classe ou d'un composant
en détaillant ses parties et leurs
interactions internes

2. Diagrammes comportementaux (8
diagrammes)

But : Décrire le comportement dynamique du


système, y compris les interactions et processus
métiers :
1. Diagramme de cas d'utilisation (Use Case
Diagram)
o Montre les interactions entre les
utilisateurs (acteurs) et le système.
2. Diagramme de séquence (Sequence
Diagram)
o Décrit l'ordre des messages échangés
entre objets dans un scénario.

2
3. Diagramme de communication
(Communication Diagram)
o Met en évidence les relations
structurelles entre objets et messages
échangés.
4. Diagramme d'activités (Activity Diagram)
o Montre le flux de travail ou les processus
métiers sous forme de diagramme de
flux.
5. Diagramme d'états (State Diagram)
o Montre les états possibles d'un objet et
les transitions entre ces états.
6. Diagramme de machines à états (State
Machine Diagram)
o Version plus formelle et détaillée du
diagramme d'états, souvent utilisé dans
des systèmes complexes.
7. Diagramme d'interaction globale
(Interaction Overview Diagram)
o Combine des éléments des diagrammes
d'activités et de séquence pour modéliser
un flux général.
8. Diagramme de timing (Timing Diagram)
o Met en évidence les contraintes
temporelles et les changements d'état
des objets au fil du temps.

Parmi tous ces diagrammes, il y en a 3 qui sont


indispensables :

 Classes (conception)
 Cas d'utilisation (analyse fonctionnelle)
 Séquence (interactions)

Et 3 autres qui sont importants selon le projet :


 Déploiement (infrastructure)
 Activités (processus métier)

2
 États (systèmes réactifs)

III.2 Diagrammes de classes

Les diagrammes de classes sont l'un des types de


diagrammes les plus couramment utilisés en UML. Ils
montrent les classes du système, leurs attributs, leurs
méthodes, et les relations entre elles. Les diagrammes
de classes sont essentiels pour comprendre la
structure statique d'un système logiciel.

III.2.1 Éléments d'un diagramme de classes.

1. Classe : Une classe est représentée par un


rectangle divisé en trois compartiments :
o Nom de la classe : Le nom de la classe
est placé dans le compartiment
supérieur.
o Attributs : Les attributs de la classe sont
listés dans le compartiment du milieu.
o Méthodes : Les méthodes de la classe
sont listées dans le compartiment
inférieur.

2. Relations : Les relations entre les classes sont


représentées par des lignes et des flèches. Les
types de relations courants incluent :
o Association : Une relation générale
entre deux classes.
o Agrégation : Une relation de type "tout-
partie" où une classe est une partie d'une
autre classe.
o Composition : Une relation de type
"tout-partie" où la partie ne peut exister
sans le tout.
o Héritage : Une relation où une classe
dérive d'une autre classe.

2
III.2.2 Exemple de diagramme de classes.

III.3 Diagramme de cas d’utilisation.

Le diagramme de cas d'utilisation est un diagramme


UML comportemental qui décrit les interactions entre
un système et ses utilisateurs (acteurs). Il montre les
fonctionnalités principales du système sous forme de
cas d'utilisation, représentant ce que le système doit
faire du point de vue de l'utilisateur.

III.3.1 Éléments du diagramme de cas d'utilisation


1. Acteurs :
o Externe au système.
o Rôles qui interagissent avec le système
(pas forcément des personnes).
o Exemple : Utilisateur, Administrateur,
Système externe.
2. Cas d'utilisation :

2
o Action ou fonctionnalité offerte par le
système.
o Représenté par une ellipse.
o Exemple : "Passer une commande",
"S'authentifier", "Consulter un compte".
3. Relations entre éléments :
o Association (lien simple) : Connecte les
acteurs aux cas d'utilisation.
o Include (<<include>>) : Un cas
d'utilisation inclut systématiquement un
autre (fonction obligatoire).
o Extend (<<extend>>) : Ajout facultatif
de fonctionnalités dans certains
scénarios.
o Généralisation : Héritage entre acteurs
ou cas d'utilisation.
4. Système :
o Limite du système, représentée par un
rectangle autour des cas d'utilisation.

III.3.2 Exemple de diagramme de cas d'utilisation.

2
III.4 Diagrammes de séquence.

Les diagrammes de séquence montrent comment les


objets interagissent dans une séquence temporelle. Ils
sont utilisés pour modéliser le comportement
dynamique d'un système en montrant les messages
échangés entre les objets au fil du temps.

III.4.1 Éléments d'un diagramme de séquence.

1. Objets : Les objets sont représentés par des


rectangles avec le nom de l'objet et le nom de la
classe.
2. Ligne de vie : Une ligne de vie est une ligne
verticale qui représente l'existence de l'objet au fil
du temps.
3. Messages : Les messages sont représentés par
des flèches horizontales entre les lignes de vie des
objets. Les messages peuvent être synchrones
(flèche pleine) ou asynchrones (flèche en
pointillé).

2
III.4.2 Exemple de diagramme de séquence

III.5 Exercices pratiques de modélisation UML


Pour renforcer votre compréhension des diagrammes
UML, voici quelques exercices pratiques :

III.5.1 Exercice 1 : Diagramme de classes


Modélisez un système de gestion de bibliothèque avec
les classes suivantes :
 Livre : Attributs : titre, auteur, ISBN. Méthodes :
getTitre(), getAuteur(), getISBN().
 Membre : Attributs : nom, numeroMembre.
Méthodes : getNom(), getNumeroMembre().
 Emprunt : Attributs : dateEmprunt, dateRetour.
Méthodes : getDateEmprunt(), getDateRetour().
Créez un diagramme de classes montrant les relations
entre ces classes.

2
III.5.2 Exercice 2 : Diagramme de séquence

Modélisez une interaction entre un utilisateur et un


système de gestion de commandes en ligne. Les
étapes sont les suivantes :
1. L'utilisateur sélectionne un produit.
2. Le système vérifie la disponibilité du produit.
3. Le système confirme la commande.
4. Le système envoie une notification de
confirmation à l'utilisateur.
Créez un diagramme de séquence montrant ces
interactions

III.5.3 Exercice 3 : Diagramme de cas d’utilisation.

Vous êtes chargé de modéliser un système de gestion


de bibliothèque en ligne. Le système permet aux
utilisateurs de rechercher des livres, de les emprunter
et de gérer leur compte utilisateur. Les
administrateurs peuvent ajouter, supprimer ou mettre
à jour les informations sur les livres disponibles.

2
CHAPITRE.IV. Concepts Avancés en
Programmation Orientée Objet.

IV.1 Exceptions et Gestion des Erreurs

IV.1.1 Concept des exceptions

Une exception est un événement qui perturbe le flux


normal d'exécution d'un programme. Elle peut être
causée par des erreurs de programmation, des
conditions d'erreur inattendues, ou des situations
exceptionnelles qui nécessitent une attention
particulière. Les exceptions permettent de gérer ces
situations de manière structurée et contrôlée, plutôt
que de laisser le programme s'arrêter brutalement ou
se comporter de manière imprévisible.
En POO, les exceptions sont souvent représentées par
des objets de classes spécifiques qui encapsulent des
informations sur l'erreur ou l'événement exceptionnel.
Cela permet de traiter les exceptions de manière
cohérente et de fournir des mécanismes pour les
capturer et les gérer.

IV.1.2 Gestion des exceptions

La gestion des exceptions en POO repose


généralement sur trois blocs de code : try, catch, et
finally.
1. Bloc try :
o Le bloc try contient le code qui peut
potentiellement générer une exception.
Si une exception se produit dans ce bloc,
le flux de contrôle est immédiatement
transféré au bloc catch.
2. Bloc catch :
o Le bloc catch est utilisé pour capturer et
gérer les exceptions. Il contient le code
qui sera exécuté si une exception est

2
levée dans le bloc try. Vous pouvez avoir
plusieurs blocs catch pour gérer
différents types d'exceptions.
3. Bloc finally :
o Le bloc finally est optionnel et contient le
code qui sera exécuté qu'une exception
soit levée ou non. Il est généralement
utilisé pour libérer des ressources ou
effectuer des opérations de nettoyage.

Voici un exemple simple en Java pour illustrer


l'utilisation de try, catch, et finally :

public class ExceptionHandlingExample {


public static void main(String[] args) {
try {
// Code qui peut générer une exception
int result = 10 / 0;
} catch (ArithmeticException e) {
// Code pour gérer l'exception
System.out.println("Erreur de division par
zéro : " + e.getMessage());
} finally {
// Code qui sera exécuté qu'une exception soit
levée ou non
System.out.println("Bloc finally exécuté.");
}
}
}

IV.2 Interfaces et Classes Abstraites

IV.2.1 Définition et utilisation des interfaces


Une interface est un contrat qui définit un ensemble
de méthodes qu'une classe doit implémenter. Elle ne
contient aucune implémentation de ces méthodes,
uniquement leurs signatures (nom, paramètres et type

2
de retour). Les interfaces sont utilisées pour définir un
comportement commun à des classes non
apparentées.

Caractéristiques principales :
 Une interface ne contient que des méthodes
abstraites (sans corps) et des constantes.
 Une classe qui implémente une interface doit
fournir l'implémentation de toutes ses
méthodes.
 Une classe peut implémenter plusieurs
interfaces, permettant ainsi l'héritage
multiple.
Syntaxe en JAVA.
interface Animal {
void manger();
void dormir();
}

IV.2.2 Implémentation d'interfaces

Pour utiliser une interface, une classe doit


implémenter celle-ci en utilisant le mot-clé
implements.

Exemple :
// Déclaration de l'interface
interface Animal {
void manger();

2
void dormir();
}

// Implémentation de l'interface
class Chien implements Animal {
public void manger() {
System.out.println("Le chien mange de la
viande.");
}
public void dormir() {
System.out.println("Le chien dort dans sa
niche.");
}
}

// Utilisation dans un programme principal


public class Main {
public static void main(String[] args) {
Animal monChien = new Chien();
monChien.manger();
monChien.dormir();
}
}

2
IV.2.3 Classes abstraites vs interfaces

Différences et similitudes

Classe
Aspect Interface
Abstraite

Mot-clé abstract interface

Méthodes abstraites
Méthodes
uniquement (Java 8+ :
Méthodes abstraites et
méthodes par défaut
concrètes
autorisées)

Héritage simple
Héritage multiple
Héritage (une seule
(plusieurs interfaces)
classe mère)

Peut avoir des Constantes


Attributs
attributs uniquement

Constructeur Peut avoir un


Pas de constructeur
s constructeur

Résumé :
 Classes abstraites : Utilisées pour regrouper
des comportements partagés, permettent une
structure de base avec des implémentations
communes.
 Interfaces : Utilisées pour spécifier des
comportements indépendants, favorisant
l'héritage multiple.

2
IV.3 Collections et Structures de Données

IV.3.1 Introduction aux collections

Les collections sont des structures de données qui


permettent de stocker et de manipuler des groupes
d'objets de manière efficace. Elles sont essentielles
pour organiser et gérer les données dans les
applications orientées objet. Les types de collections
les plus courants incluent les listes, les ensembles, et
les dictionnaires.

1. Listes

Une liste est une collection ordonnée d'éléments, où


chaque élément a une position spécifique (index). Les
listes permettent de stocker des éléments de
différents types et de les accéder par leur index. Les
opérations courantes sur les listes incluent l'ajout, la
suppression, et l'accès aux éléments.

Exemple en PHP :
<?php
$list = [1, 2, 3, 4, 5];

// Ajouter un élément
$list[] = 6;

// Supprimer un élément
unset($list[2]);

// Accéder à un élément
echo $list[0]; // Affiche 1
?>

2
2. Ensembles

Un ensemble est une collection non ordonnée


d'éléments uniques. Les ensembles sont utiles pour
des opérations mathématiques telles que l'union,
l'intersection, et la différence. Ils garantissent que
chaque élément est unique, ce qui les rend idéaux
pour des situations où les doublons doivent être
évités.

Exemple en PHP :
<?php
$set = [1, 2, 3, 4, 5];

// Ajouter un élément
$set[] = 6;

// Supprimer un élément
$set = array_diff($set, [3]);

// Vérifier l'existence d'un élément


if (in_array(4, $set)) {
echo "4 est dans l'ensemble.";
}
?>
3. Dictionnaires

Un dictionnaire est une collection de paires clé-valeur,


où chaque clé est unique et associée à une valeur
spécifique. Les dictionnaires permettent un accès
rapide aux valeurs via leurs clés, ce qui les rend très
efficaces pour les opérations de recherche.

Exemple en PHP :
<?php
$dictionary = [
"name" => "John",

2
"age" => 30,
"city" => "New York"
];

// Ajouter une paire clé-valeur


$dictionary["country"] = "USA";

// Supprimer une paire clé-valeur


unset($dictionary["age"]);

// Accéder à une valeur


echo $dictionary["name"]; // Affiche John
?>

IV.3.2 Utilisation des collections dans la POO

Les collections sont souvent utilisées dans la POO pour


gérer des groupes d'objets de manière efficace. Elles
permettent de structurer les données de manière
organisée et de faciliter les opérations courantes telles
que l'ajout, la suppression, et l'accès aux éléments.
Voici quelques exemples pratiques de l'utilisation des
collections dans la POO.

2
CHAPITRE.V. Design Patterns

V.1 Introduction aux Design Patterns

V.1.1 Définition et Importance des Design Patterns

Les design patterns ou patrons de conception sont des


solutions générales et réutilisables à des problèmes
courants rencontrés dans le développement logiciel.
Ils représentent des pratiques éprouvées et
documentées qui permettent de structurer le code de
manière efficace, en améliorant sa lisibilité, sa
maintenabilité et sa flexibilité.
L'importance des design patterns réside dans leur
capacité à faciliter le développement logiciel en
fournissant un vocabulaire commun aux développeurs.
Ils permettent également de réduire les erreurs,
d'accélérer le processus de développement et de
rendre le code plus adaptable aux changements
futurs.

V.1.2 Objectifs des Design Patterns


Les design patterns poursuivent plusieurs objectifs
clés :
 Réutilisabilité : Encourager l'utilisation de
solutions standardisées pour résoudre des
problèmes communs.
 Extensibilité : Faciliter l'ajout de nouvelles
fonctionnalités sans modifier le code existant.
 Flexibilité : Permettre l'évolution des systèmes
avec un minimum de perturbations.
 Maintenance : Rendre le code plus facile à lire,
comprendre et maintenir.

2
 Standardisation : Fournir un langage commun
aux développeurs pour décrire les solutions.

V.1.3 Patterns de Création.


Les patterns de création concernent l'instanciation
d'objets. Ils permettent de créer des objets de
manière contrôlée et flexible, tout en masquant la
logique complexe de création.
Exemples de Patterns de Création
1. Singleton :
o Définition : Assure qu'une classe ne
possède qu'une seule instance et fournit un
point d'accès global à cette instance.
o Exemple d'utilisation : Gestionnaire de
configuration, gestion de connexion à une
base de données.
2. Factory Method :
o Définition : Définit une interface pour
créer des objets, mais laisse les sous-classes
décider de la classe à instancier.
o Exemple d'utilisation : Systèmes de
gestion de contenu, créateurs de documents.
3. Abstract Factory :
o Définition : Fournit une interface pour
créer des familles d'objets sans spécifier
leurs classes concrètes.
o Exemple d'utilisation : Systèmes
d'interfaces graphiques multi-plateformes.

2
4. Builder :
o Définition : Sépare la construction
complexe d'un objet de sa représentation,
permettant de créer différents types d'objets
avec le même processus.
o Exemple d'utilisation : Générateurs de
rapports, générateurs d'objets complexes.
5. Prototype :
o Définition : Permet de créer de
nouveaux objets en clonant des instances
existantes.
o Exemple d'utilisation : Gestion de projets
avec modèles préconfigurés.

V.1.4 Patterns de Structure


Les patterns de structure traitent de la composition
des classes et des objets. Ils facilitent la création de
structures complexes tout en assurant leur
extensibilité et leur maintenance.
Exemples de Patterns de Structure
1. Adapter :
o Définition : Convertit l'interface d'une
classe en une autre interface que les clients
attendent.
o Exemple d'utilisation : Adaptation de
systèmes hérités à de nouvelles interfaces.
2. Bridge :
o Définition : Sépare l'abstraction d'une
classe de son implémentation pour qu'elles
puissent évoluer indépendamment.

2
o Exemple d'utilisation : Systèmes de
rendu graphique multi-plateformes.
3. Composite :
o Définition : Permet de composer des
objets en structures arborescentes pour
représenter des hiérarchies "tout-partie".
o Exemple d'utilisation : Structures de
fichiers, arbres DOM HTML.
4. Decorator :
o Définition : Ajoute dynamiquement de
nouvelles fonctionnalités à un objet sans
modifier son code source.
o Exemple d'utilisation : Systèmes de
gestion des fenêtres dans les interfaces
graphiques.
5. Facade :
o Définition : Fournit une interface
simplifiée à un ensemble de classes
complexes.
o Exemple d'utilisation : Interfaces de
bibliothèques complexes.
6. Flyweight :
o Définition : Utilise le partage pour
prendre en charge efficacement un grand
nombre d'objets similaires.
o Exemple d'utilisation : Gestion des
caractères dans les éditeurs de texte.

2
7. Proxy :
o Définition : Fournit un substitut ou un
intermédiaire à un autre objet pour contrôler
l'accès à celui-ci.
o Exemple d'utilisation : Gestion des
connexions réseau, cache de données.

V.1.5 Patterns de Comportement


Les patterns de comportement se concentrent sur les
interactions entre les objets, définissant la manière
dont ils collaborent et communiquent.
Exemples de Patterns de Comportement
1. Chain of Responsibility :
o Définition : Permet à plusieurs objets de
traiter une demande, chaque objet ayant la
possibilité de la traiter ou de la transmettre à
un autre.
o Exemple d'utilisation : Gestion des
requêtes HTTP.
2. Command :
o Définition : Encapsule une requête en
tant qu'objet, permettant de paramétrer les
actions, d'annuler ou de rejouer des
opérations.
o Exemple d'utilisation : Systèmes de
menus et commandes dans les interfaces
graphiques.
3. Observer :

2
o Définition : Définit une relation de
dépendance un-à-plusieurs entre des objets,
de sorte que lorsque l'état d'un objet change,
tous ses dépendants sont notifiés.
o Exemple d'utilisation : Systèmes de
gestion d'événements.
4. State :
o Définition : Permet à un objet de
changer son comportement en fonction de
son état interne.
o Exemple d'utilisation : Automates à
états finis.
5. Strategy :
o Définition : Définit une famille
d'algorithmes, encapsule chacun et les rend
interchangeables.
o Exemple d'utilisation : Moteurs de
recherche avec stratégies de tri.
6. Visitor :
o Définition : Sépare un algorithme de la
structure de l'objet sur lequel il opère.
o Exemple d'utilisation : Parcours d'arbres
syntaxiques dans les compilateurs.
En utilisant ces design patterns, les développeurs
peuvent produire des applications mieux conçues,
plus robustes et plus faciles à maintenir.

2
CONCLUSION

La programmation orientée objet offre une approche


structurée et modulaire pour le développement de
logiciels.

En utilisant des concepts tels que les classes et les


objets, l'encapsulation, l'héritage, le polymorphisme,
et l'abstraction, la POO permet de créer des systèmes
logiciels flexibles, réutilisables, et faciles à maintenir.

En résumé, la POO repose sur des concepts clés tels


que les classes et les objets pour encapsuler les
données et les comportements, l'héritage pour la
réutilisation du code, les interfaces et les classes
abstraites ajoutent une couche supplémentaire de
flexibilité et de contrôle, permettant de définir des
contrats et des comportements communs que les
classes doivent respecter. La gestion des exceptions
et des erreurs assure une exécution contrôlée et
prévisible des programmes, tandis que les collections
et les structures de données facilitent la manipulation
et l'organisation des données.

En maîtrisant ces concepts clés, vous serez bien


équipé pour aborder des projets de développement
logiciel plus complexes et pour créer des applications
robustes et évolutives. La POO est une compétence
essentielle pour tout développeur moderne, offrant
une base solide pour la conception et l'implémentation
de systèmes logiciels efficaces et maintenables.

2
BIBLIOGRAPHIE

1. Alexis DROGOUL, Conception Orientée Objet:


Support de Cours, Université Paris 6, Maîtrise
d’Informatique, 2001-2002.
2. David Morin, La programmation orientée objets,
DESS-QUASSI, Université d’Angers 2002-2003.
3. S. Rosmorduc, « Introduction à JDBC »,
Université Paris 8
4. Cours de E. Cariou, « Introduction à JDBC :
Accès aux bases de données en Java »,
Université de Pau et des Pays de l'Adour
5. Cours de M. Bonjour, « Java et les bases de
données », Université de Genève
6. Cours de D. Fournier, « JDBC », Université de Le
Havre
7. Rm di Scala, Initiation à Java 2, Berti, Algérie,
Novembre 2004
8. http://www.oracle.com/technetwork/java/
overvie -141217.html
9. Maurers, Baufeld, Müller & al, Grand livre Java
2, Micro Application, Paris (1999)
10.https://fr.wikipedia.org/wiki/
Java_Database_Connectivity Présentations :
11.http://docs. sqlserver.fr/7.4/jdbc-use.html
12.http://www.berti-editions.com

2
TABLES DES MATIERES
PLAN DU COURS...............................................................i
0. INTRODUCTION.........................................................1
0.1. Objectif..................................................................1
0.2. Pré requis..............................................................1
CHAPITRE.I. GENERALITES............................................3
I.1 Les langages de programmation...........................3
I.1.1 Définition............................................................4
I.1.2 Utilisation...........................................................6
I.1.3 Notions courantes...............................................6
I.1.4 Paradigmes.........................................................8
I.1.5 Mise en œuvre..................................................13
I.2 Origines de la POO...............................................15
I.3 Objectifs de la POO..............................................15
I.4 Les langages Orientés Objet................................16
CHAPITRE.II. CONCEPTS FONDAMENTAUX...............18
II.1 Objets..................................................................18
II.2 Classe..................................................................19
II.3 Encapsulation......................................................20
II.4 Héritage...............................................................20
II.5 Polymorphisme....................................................21
CHAPITRE.III. UML (Unified Modeling Language).......22
III.1 Introduction à UML...............................................22
III.2 Diagrammes de classes.......................................25
III.2.1 Éléments d'un diagramme de classes..............25
III.2.2 Exemple de diagramme de classes..................26
III.3 Diagramme de cas d’utilisation...........................26
III.3.1 Éléments du diagramme de cas d'utilisation....27
III.3.2 Exemple de diagramme de cas d'utilisation.....28
III.4 Diagrammes de séquence...................................28
III.4.1 Éléments d'un diagramme de séquence...........28
III.4.2 Exemple de diagramme de séquence..............29
III.5 Exercices pratiques de modélisation UML............29
III.5.1 Exercice 1 : Diagramme de classes..................29
III.5.2 Exercice 2 : Diagramme de séquence..............30
III.5.3 Exercice 3 : Diagramme de cas d’utilisation.....30
CHAPITRE.IV. Concepts Avancés en Programmation
Orientée Objet. 31
IV.1 Exceptions et Gestion des Erreurs.......................31

2
IV.1.1 Concept des exceptions...................................31
IV.1.2 Gestion des exceptions....................................31
IV.2 Interfaces et Classes Abstraites...........................32
IV.2.1 Définition et utilisation des interfaces..............32
IV.2.2 Implémentation d'interfaces.............................33
IV.2.3 Classes abstraites vs interfaces.......................35
IV.3 Collections et Structures de Données..................36
IV.3.1 Introduction aux collections..............................36
IV.3.2 Utilisation des collections dans la POO.............38
CHAPITRE.V. Design Patterns...................................39
V.1 Introduction aux Design Patterns.........................39
V.1.1 Définition et Importance des Design Patterns. .39
V.1.2 Objectifs des Design Patterns...........................39
V.1.3 Patterns de Création.........................................40
V.1.4 Patterns de Structure.......................................41
V.1.5 Patterns de Comportement..............................43
CONCLUSION.................................................................45
BIBLIOGRAPHIE..............................................................46
TABLES DES MATIERES..................................................47

Vous aimerez peut-être aussi