Vous êtes sur la page 1sur 23

2 Concepts de base de la programmation orientée objet

2.1. Le paradigme objet


2.1.1 Approche de la définition des objets
Un paradigme contient les règles selon lesquelles le réel va être perçu, ce que l'on appelle les
principes d'intelligibilité.

Espace de problème-Espace de solution


L'espace de problème est l'environnement dans lequel se déroule l'informatisation,
environnement à la fois organisationnel et technique, mais surtout sémantique ou culturel.
L'espace de solution est le discours dans lequel s'élabore la solution. Il est caractérisé par une
modélisation fondée sur des structures de représentation et contrainte par des catégories à priori.
Autrement dit, l'espace de solution est une réduction assortie d'une projection.

Ces catégories mentales ou ces structures de représentation diffèrent d'une méthode à l'autre. On
croira épuiser toute la signification d'un domaine, mais c'est faux : on ne produira jamais qu'une
vue subjective, limitée par la finitude de nos schémas de pensée. La modélisation est toujours un
homomorphisme. Pour le succès de l'informatisation, le concepteur doit absolument être averti de
cette limitation et de la distorsion conséquente. Bien des conflits entre l'utilisateur et
l'informaticien viennent de là.
Comment limiter, voire supprimer la distorsion entre l'espace de problème et l'espace de
solution? Comment maîtriser le processus mental de la modélisation ?
Dans la représentation de l'utilisateur, dans sa pratique, quelle est l'unité de perception qui est
manipulée mentalement ? Données, actions, traitements, fonctions, systèmes, règles … ? Ces
réponses se situent dans des cadres souvent étrangers aux utilisateurs ou jugés artificiels, soit que
ces cadres dérivent trop directement de la technique informatique (données, traitements) soit
qu'ils renvoient à des appareils conceptuels ignorés(fonctions mathématiques, logique, systèmes ).
La réponse qui semble plus proche de la représentation naturelle est : l'utilisateur perçoit dans sa
pratique des « entités » stables, douées d'autonomie, et qui se manifestent par des informations
accessibles et des comportements : des objets.

2.1.2. Le concept d'objet


L'objet est une représentation d'une portion cohérente de la réalité. La cohérence est liée à
l'adéquation de l'objet, soit à une entité réelle, soit à un concept. L'objet est plus que la donnée ou
l'entité du modèle entités-relations, plus même qu'un groupement de données et de traitements:
il est un modèle exact et complet d'un objet du monde réel. Donc un objet est une entité associant
données et programmes. Il existe un rapport très étroit entre objet et classe au point de
confondre les deux. L'objet est une occurrence d'une classe.
Instance d'une classe: cette expression est synonyme d'objet. L'objet n'existe que pendant
l'exécution prolongée par le stockage
Classe : la classe correspond à la notion de module auquel on aurait agrégé une structure de
fichier, elle existe dans le programme comme séquence d'instructions du langage; elle existe
également pendant l'exécution comme code, et parfois à travers des variables de classe
(typiquement le compteur des objets ou une information à appliquer à toutes les instances).
L'objet modèle puis l'objet informatique se calquent sur l'objet réel. Ce dernier est une entité de
l'espace du problème, accessible par deux aspects:
- présent dans le monde réel
- présent dans la représentation du réel ( univers, discours)
Concepts de base de la programmation orientée objet
Selon les cas il sera plus facile d'observer discrètement la réalisation ou d'analyser la présentation;
l'informatique industrielle penchera pour la première solution; l'informatique de gestion pour la
seconde. Les attributs constitutifs de l'objet en tant qu'entité du monde réel sont la cohérence,
l'autonomie, la résistance. Ces termes renvoient respectivement à la logique, à la théorie des
systèmes, à l'action.

2.1.3. Généralité du concept objet


A la question « qu'est ce qu'un objet ? » on serait tenté de répondre d'une manière aussi simple:
<<un objet est ce qui est>>, Une telle réponse laisse au concept objet toute sa généralité et c'est
dans cette généralité que le concept objet trouve sa force opératoire. Mieux encore que l'aspect
général, son coté naturel le distingue des autres structures de représentation. Cela débouche sur
un précepte de modélisation: les objets pertinents pour le système sont ceux que l'utilisateur
identifie naturellement.
Naturellement s'entend comme instantanément, sans effort de reformulation, directement en
rapport avec la représentation mentale de l'utilisateur. L'effort de reformulation s'avère inutile
parce que la structure objet colle à la réalité. Ainsi le fossé entre espace de problème et espace de
solution est suffisamment comblé par la modélisation objet pour aller jusqu'à énoncer: <<observer
c'est modéliser>>.
Ainsi nous pouvons dire sans ambages: <<Tout est objet>>. Cette formule se rencontre assez
souvent. Sa concision ne doit pas masquer sa capacité pratique: elle a été réellement
implémentée par certains langages, par exemple SmallTalk.

2.1.4 Lien avec le paradigme systémique


Un système est un ensemble d'objets organisés en fonction d'un but. Cette définition d'un
système en tant qu'ensemble a été critiquée malgré le fait que cette formule a l'avantage de la
concision. La notion d'objet telle qu'elle est ici utilisée recouvre la nôtre : objet ou élément du
monde réel ou conceptuel.
Distinction entre les deux approches (systémique et orientée objet) :
- l'orienté objet se focalise sur l'identification et la définition des objets
- le systémique traite plutôt les aspects structurel, relationnel
Trois idées essentielles forgent la notion du système
- l'autonomie dans l'environnement
- la cohérence assurée par l'interdépendance d'éléments en interaction
- la permanence conservée malgré les modifications.
Ces idées, si elles ne s'appliquent pas directement à l'objet, interviennent significativement dans
la modélisation objet, laquelle peut s'envisager comme la production d'un <<système des
objets>>. Il n'est pas un précepte de la démarche systémique qui ne puisse s'appliquera la lettre à
la démarche objet.
o La modélisation systémique applique sur la réalité un modèle lui permettant d'accéder à une
certaine intelligibilité : Le modélisateur prend conscience de la restriction opérée par son modèle,
et l'impute explicitement à son intention. Il est donc théoriquement capable d'en rendre compte.
o La modélisation objet procède de même, mais dispose d'un schéma de représentation plus
simple : l'objet en tant qu'encapsulation de données et de traitements, la classe en tant
que type abstrait.
La jonction entre les deux courants s'établit, en considérant l'objet comme l'unité de base et le
terme de la décomposition du système. On rejoint la notion d'implexe définie par Jean Louis
Lemoigne
Implexe: caractérise une unité d'action indécomposable, irréductible pourtant à un
élément unique
La deuxième partie de cette définition formule le constat selon lequel l'implexe conserve une
certaine complexité impossible à réduire (sous peine de déformer la réalité). Au-delà de la
Page 2/23
Concepts de base de la programmation orientée objet
coïncidence entre l'objet et l'implexe, de nombreuses notions du paradigme systémique
correspondent à des notions de l'orienté objet. L’autonomie renvoie à la localité; la cohérence à la
notion de type abstrait: l'interaction aux notions connexes de message, contrat, responsabilité et
comportement.
En définitive, le paradigme objet hérite légitimement du paradigme systémique.

2.1.5 Implémentation progressive


La généralité des catégories objet alliée au caractère naturel des objets se traduit par une chaine
d'implémentation sans rupture:
 on repère l'objet réel, c'est- à- dire l'objet dans le monde réel
 on formule l'objet modèle dans l'espace de représentation c'est-à-dire le modèle
 on l'implémente en objet informatique
La puissance de la démarche objet réside indubitablement dans la linéarité et la continuité de
l'implémentation. Contrairement aux démarches traditionnelles, à aucun moment le
développement ne rencontre de rupture : aucun changement de niveau n'oblige à remodeler la
physionomie du système. Sauf erreur ou réorientation, ce qui est objet au début se retrouve objet
à la fin, ayant conservé la même définition fonctionnelle. Même quand les approfondissements
amènent à déclarer des composants d'un objet initial, cet objet subsiste sans qu'il soit besoin de le
redéfinir dans sa finalité ou son interface.
Cette chaîne d'implémentation garantit la continuité, et autorise le recours au prototypage
comme cycle de développement.

2.1.6 Critère de décomposition


Pour la démarche objet, le critère de décomposition s'impose : c'est l'objet.
On appelle « orienté-objet » toute méthode dont le critère de décomposition horizontale est
l'objet, en tant qu'abstraction d'un objet du monde réel.
Pour être précis, le composant de base que l'on trouve dans le logiciel est la classe comme
abstraction d'un ensemble d'occurrences : les objets, nommés également instances de la classe.
Cette unité de décomposition du logiciel est la même que l'unité de perception du réel.
L'unité manipulée par l'utilisateur est sans conteste l'objet comme occurrence concrète, mais on
peut supposer que l'utilisateur se livre plus ou moins consciemment à une généralisation qui lui
permet d'identifier des entités abstraites correspondant aux classes. En programmation classique,
l'unité minimale à laquelle aboutit la décomposition est la procédure ou la fonction ou encore le
bloc d'instructions. Il s'agit donc d'un traitement ou d'une action, éléments beaucoup moins riches
de sens et également moins stables.
Le fait d'utiliser la même unité tout au long du développement est à la base de la chaîne
d'implémentation et a des conséquences importantes sur l'architecture du logiciel comme sur son
évolution.
Architecture du logiciel : collection de classes, collection que ne contraignent pas l'arbre
d'héritage, ni les connexions d'instances. Loin d'être une contrainte qui pèse sur l'architecture du
logiciel, la représentation de l'héritage fournit un moyen précieux pour maîtriser la perception du
système pendant le développement. De plus, la réalisation de l'héritage (dans les programmes)
favorise la productivité et l'évolutivité.
A l'exécution, les objets sont créés selon les besoins et établissent entre eux les connexions
correspondant à la vocation de chacun (responsabilité ou contrat); les objets se trouvent donc
lâchés dans leur environnement ou ils se comportent selon leur nature. C'est pourquoi les
considérations sur les traitements ne bouleversent en rien l'architecture du logiciel. En aucun cas
elles n'introduisent une complexité supplémentaire ; tout juste peuvent-elles aboutir à la création
d'objets techniques absents de l'univers du discours, mais cette création ne change pas la structure
du logiciel.

Page 3/23
Concepts de base de la programmation orientée objet
L'évolution est grandement facilitée puisqu'une modification dans l'implémentation d'un objet n'a
aucune conséquence sur les autres objets, quand les conditions suivantes sont satisfaites :
le précepte de localité est respecté.
la modélisation a su dégager les types abstraits exprimant correctement la sémantique du
discours et de l'action.
la modification ne redéfinit pas l'objet dans sa fonction, donc ne touche pas à son interface.
Il arrive que l'interface d'un objet évolue sans que la définition fonctionnelle et contractuelle soit
modifiée. Ce cas de figure se présente quand on retouche la délégation des services. La
propagation d'une telle modification se limite au voisinage immédiat de l'objet.

2.1.7 Les problèmes soulevés


a) Approche ontologique (ce qu'est l'objet) et considération économique
L'approche orientée objet focalise avant tout sur ce qu'est l'objet avant de s'interroger sur
comment il est utilisé. La deuxième question ne se borne pas à l'étude du comportement de
l'objet ni ne la monopolise. En effet:
 d'une part en s'interrogeant sur l'être de l'objet, l'analyste le prend nécessairement mais pas
uniquement selon l'aspect comportemental
 d'autre part, en demandant comment l'objet est utilisé, l'analyste aborde l'interaction de l'objet
avec l'utilisateur (ou l'environnement ) plus que le seul comportement de l'objet.
L'approche orientée objet s'interroge en priorité sur l'essence de l'objet, essence considérée
comme la source du sens (valable surtout pour l'analyse). Cette priorité accordée à l'étude
ontologique recouvre une tendance naturelle de l'esprit humain. Elle paraît favoriser la
modélisation mais présente un revers.
Revers de la priorité ontologique : risque d'entraîner un surcroît des développements car la
modélisation n'est plus bornée par le besoin immédiat, l'application telle que prévue par le cahier
de charges. L'analyste à la fois requis par l'étude ontologique et mobilisé par la généralisation,
modélise les objets suivant ce qu'il observe et en cherchant à en rendre le maximum de sens. Ce
sens déborde souvent et de beaucoup, l'immédiat besoin d'informatisation. L'analyste risque donc
de se laisser entraîner dans une approche sans fin des objets. Deux visées acceptent cette
tendance : la réutilisabilité et l'extensibilité.
Exemple : Informatisation du traitement des commandes
Analyse orientée objet : Pourquoi il y a t- il des commandes ? parce qu'il y a des produits. Certains
caractéristiques des produits semblent influencer sur le traitement des commandes : stocks
disponibles, taux de remise, composition des lots, etc.. Et nous voilà engagés dans la modélisation
des produits, entraînés d'exception en dérogation, dans une analyse sans fin, qui nous mène
certainement en dehors du cadre du projet donc en dehors du budget.
Cet exemple veut tout juste montrer qu'à utiliser trop naïvement le principe orienté objet que
nous avons nommé priorité ontologique, nous nous privons d'un critère d'arrêt.

Les méthodes fonctionnelles au moins nous offraient un critère d'arrêt simple à partir de la
question "que faut-il faire ?: d'où, observant le réel, " A quoi ca sert" qui se précise en " est-ce que
ça sert ?". Le cahier de charges ou la demande de service s'exprime naturellement en termes de
fonctions : "moi, Bazor, Directeur de la société BAZORIX SARL, je veux que la gestion des clients
soit automatisée. Il faudra développer : l'enregistrement des clients, le suivi des gros clients, le
traitement des commandes...". L'approche fonctionnelle respecte ces termes et maintient le
découpage des fonctions, généralement jusqu'à l'implémentation.
Au contraire de la fonction, l'objet n'est pas lui-même un critère d'arrêt pour l'analyse. Il faudra
donc que la méthode orientée objet se dote d'un tel critère et cela dans deux dimensions :
 L'extension : de quels objets parler, jusqu'où aller les chercher;
 La profondeur : quelle précision viser; quel contenu de sens appréhender

Page 4/23
Concepts de base de la programmation orientée objet

b) L’identification des Objets et classes n’est pas facile


Bertrand Meyer insiste sur le caractère naturel des objets, caractère dont découle la facilité
d’identification. Pour lui les objets existent dans la réalité ou plus exactement dans le modèle du
monde ‘Les objets logiciels reflètent tout simplement les objets externes ’
Mais il s'empresse d'ajouter que l'identification des classes puis leur définition n'est pas aussi
aisée. D'autre part, le processus d'abstraction et le souci de la réutilisabilité introduisent des
classes auxquelles ne correspond aucun objet réel: ce sont les classes abstraites.
D'autre part, la spécification d'une classe comme type abstrait de données et la définition
rigoureuse des interfaces et des contrats exigent de grands talents.
Peter Coad et Edward Yourdon en rajoutant s'en prenant à Meyer : " les objets sont juste là pour
être relevés (Meyer 1988]. Des noix ! A l'intérieur du domaine du problème ou du contexte, les
classes et objets pertinents sont rarement " juste là pour être relevés".

Conflit d'héritage
Article

Emballer()

Objet_Fragile
Produit_Fermier
_Fermier
Emballer :
Emballer : Emballer :
utiliser papier
Emballer : utiliser conditionner avec
utiliser papier isolant les
papier isolant les carton solide
isolant les
odeurs odeurs
odeurs

Œufs
‘‘Héritage’’

c) les deux principes de structuration des classes sont parfois confondus.


II s'agit de l'héritage et de l'assemblage. La classe tarte_aux_pommes n'hérite pas des classes
pomme et pâte_à_tarte, elle s'en compose.

d) l'héritage multiple présente un risque de confusion(Figure conflit d'héritage).


Il s'agit des conflits d'héritage dont la résolution demande une vigilance particulière dès l'analyse.
Dans les classes Produit_Fermier et Objet_Fragile ont surchargé la définition de la méthode
emballer. La classe Œufs hérite de ces deux classes. Comment doit- on emballer les œufs ? Cet
exemple de conflit d'héritage nous met sur la voie d'une remise en cause des classes:
Objet_Fragile n'est certainement pas une classe à isoler sur le même pied que Produit_Fermier.
La fragilité est une qualité des articles en général, non un critère d'existence ou de spécialisation
des objets. Les conflits d'héritage trouvent des solutions différentes selon les langages. Ils se
posent dès l'analyse.

e) une fois les objets identifiés, il faut encore les délimiter rigoureusement et déterminer ce
qu'ils feront réellement. Intervient alors la notion de délégation : un objet, responsable d'un
contrat ne réalise pas nécessairement lui-même toutes les actions liées à ce contrat. II délèguera
une partie de ses responsabilités.
Page 5/23
Concepts de base de la programmation orientée objet
Nouveau casse-tête pour le modélisateur ! Que déléguer ? Comment peut-on déléguer, sous
quelles contraintes ? etc.

f) la communication entre les objets : faut-il choisir entre souplesse et simplicité ?


Lors de l'exécution, les liens entre les objets (connexions d'instances) se réalisent exclusivement
sous la forme d'envoi de messages. C'est la une conséquence du principe de masquage de
l'information : les méthodes et l'information vitale portées par un objet ne sont accessibles qu'à
travers l'interface de l'objet. L'objet client doit donc demander à l'objet fournisseur d'activer ses
méthodes ou de lui retourner de l'information.
Ce mécanisme simplifie la compréhension et la maintenance de logiciels. Mais une question surgit
: un objet peut-il prendre l'initiative de communiquer avec un autre objet qu'il n'a pas créé ? Plus
généralement les catégories de l'orienté objet et les schémas de représentation ne favorisent pas
la modélisation des aspects dynamiques du système.
Dans la programmation classique (à l'exclusion de la programmation fonctionnelle qui de ce point
de vue est très proche de la programmation objet et à l'exclusion de la programmation parallèle),
la dynamique des traitements se perçoit assez facilement dans la linéarité du source. Il y a bien à
l'échelle du programme et du module quelques ruptures de linéarité dont l'ordinogramme rend
très bien compte.
Il n'en va plus de même pour l'approche objet. Nous étudierons par la suite les représentations
disponibles pour modéliser la dynamique d'un système ; elles se limitent à deux catégories:
 la représentation des connexions au niveau du système logiciel (équivalent au graphe d'appel).
 le diagramme état transition au niveau des classes.
Certes au niveau des méthodes de la classe (services, fonctions, procédures) on peut toujours
dessiner l'ordinogramme ou le graphe de contrôle. Mais étant donné la taille moyenne des
méthodes, cela risque de présenter peu d'intérêt.
En tout cas l'on dispose d'aucun outil pour modéliser le comportement de tout système logiciel
dans le temps. L'approche objet est essentiellement statique : elle réussit très bien à définir
pratiquement les classes et les relations de voisinage de ces classes. Mais elle reste dans le flou
quant a la dynamique du système.

2.2. Les principes du paradigme objet


Le terme «principe » est pris dans deux de ses acceptions(sens) qu’il faudra nettement distinguer
pour plus de clarté :
 Principes comme fondements théoriques, propositions caractéristiques, directives
auxquelles tout le développement ultérieur devra être subordonner.
 Principes comme règle de conduite (Ex : principe morale), règle ou norme d’action
clairement représentée à l’esprit, énoncée par une formule.
Dans la première acceptation, il est question des principes d’intelligibilité (abstraction,
classification, agrégation, et coopération). Dans le deuxième sens, il sera question des principes
opératoires ou principes pratiques. Ils viennent en conséquence des premiers, ce qui est garant de
la cohérence méthodologique. Il s’agit de la réification et la structuration.
C’est autour de ces principes que s’organisent les différentes notions qui compose l’approche
orientée objet.

Page 6/23
Concepts de base de la programmation orientée objet

Principes d’intelligibilité
1

Abstraction Classification Agrégation Coopération


2 3 4 5
-----
- Classes - Généralisation - Composition - - Délégation
- Instanciation Spécialisation - Composition
- Propriétés actives - Généricité
Informatives Polymorphisme
- Encapsulation

Eléments classes, objets (=instances)Classes abstraites


et Attributs et méthodes virtuelles, méthodes
virtuelles
Procédés Masquage de l’information Héritage, surcharge Assemblage Envoie de messages
Interface liaison dynamique connexion d’instances
Liaison tardive

Principes
Pratiques Structuration Réification
7 6

- Principes de continuité - Représentation


- Programmes et bibliothèques - Factorisation

Les quatre(4) principes d’intelligibilité entrainent le principe de la réification

2.2.1 Les principes d’intelligibilité


Toute méthode de modélisation (pris dans son sens le plus large. Cela ne concerne pas seulement
les phrases en amont du développement logiciel. Même un programme est un modèle de la
réalité) excipe d’un méta modèle, i.e. d’une structure a priori plaquée sur le réel afin d’en extraire
la signification utile. Le méta modèle fonctionne donc comme une grille de lecture, qui à la fois

Page 7/23
Concepts de base de la programmation orientée objet
cache et fait voir. De ce méta modèle à priori dépend tout le reste. Chaque élément du méta
modèle renvoie à un ensemble de faits du monde réel, regroupés en une structure unique.
Par exemple : les entités, les opérations, mais aussi les synchronisations, les règles, démons,
triggers, etc.
Le développeur se charge de cet appareillage conceptuel comme le plombier d’une boite à outils.
Il y trouve une aide pour comprendre le réel, l’analyser, le modéliser et, éventuellement, le
transformer.
Définition : Ces outils conceptuels sont les principes d’intelligibilité, ce par quoi le monde nous
devient compréhensible et la matière manipulable.

2.2.2 Abstraction
La première évidence, le premier principe de perception, c’est l’objet. L’objet est perçu comme
une entité cohérente rassemblant des propriétés.
Mais si on en reste là, on se contente d’un recensement. Il faut encore ordonner les objets en
ensembles significatifs. Pour cela, l’on se fonde sur les similitudes des propriétés observées et l’on
fait part de l’accident. L’on aboutit à des ensembles d’objets présentant les mêmes
caractéristiques. Ces ensembles sont appelés des classes ce travail applique le procédé de
l’abstraction.
Définition : L’abstraction est l’action de l’esprit qui, à partir d’une donnée, en extrait une
signification utile et construit une idée (ou concept) manipulable intellectuellement.
L’abstraction diffère de l’analyse en ce que celle-ci considère également tous les éléments de la
représentation analysée. Au contraire, l’abstraction porte sur des traits représentatifs des objets
et pertinents pour le besoin de la réflexion.
Il existe quatre sens qui pourront fonder des opérations précises au sein d’une méthode d’analyse-
conception (Analyse empruntée à l’Encyclopédie universalis).
 Abstraction par simplification
Opération de l’esprit par laquelle on néglige « toutes circonstances environnant
un acte », on ne tient pas compte « des accidents d’une substance », et on ne
s’arrête pas aux particularités d’un être ».
C’est l’attitude opératoire qui devrait permettre à l’esprit scientifique de
déterminer expérimentalement un ensemble de rapports constants entre faits
pour en abstraire inductivement une loi.
Elle est un préalable à toute idéation.
 Abstraction par généralisation
Opération de l’esprit par laquelle on remonte des éléments (aussi complexes
soient-ils) vers des propriétés plus générales.
Cette opération se révèle à travers les propriétés opératoires du langage
humain.
Elle trouve sa plus haute expression dans la logique des classes
Elle est nécessaire à la conceptualisation.
 Abstraction par sélection
Opération de l’esprit par laquelle on isole, à partir d’une donnée quelconque, un
trait spécifique quelconque, une détermination considérée en elle-même (par
exemple, la blancheur de la plage blanche).
Elle est à l’œuvre dans la classification.
 Abstraction par schématisation
Opération de l’esprit par laquelle on analyse le phénomène et on le restitue
comme « système de données »
C’est l’acte de la modélisation.
Page 8/23
Concepts de base de la programmation orientée objet
L’Encyclopaedia universalis ajoute : « Dans ces quatre significations, l’abstraction est un travail
formel, structurant la donnée selon quatre opérations mentales bien distinctes : simplification,
généralisation, sélection, schématisation. Celles-ci correspondent à quatre processus de
cognition : idéation, conceptualisation, classification, modélisation. On voit le profit qu’on peut
tirer de cette approche rigoureuse quand il s’agit d’élaborer une méthode d’analyse-conception.
a) Classes

Après abstraction, l’analyse-concepteur obtient des classes. Une classe étant un ensemble d’objets
présentant les mêmes caractéristiques. En d’autres termes, une classe regroupe des objets ayant
les caractéristiques communes.
En technologie orientée objet, une classe est un élément logiciel, composant élémentaire d’une
application orientée objet.

b) Instanciation
L’objet est une unité de signification, dont la structure et les comportements sont définis dans sa
classe d’appartenance. Il n’existe que pendant l’exécution ou à travers un organe de persistance,
contrairement à la classe dont la durée de vie est celle du logiciel. L’objet est nommé aussi
instance de classe, ce qui a le mérite d’éviter la confusion, entre l’objet informatique (instance
d’une classe-programme) et l’objet du monde réel.
Le mécanisme par lequel l’exécution d’un programme produit un objet d’une classe est
l’instanciation. Tous les langages orientées objet en disposent : New : (<nom de la classe>,
<paramètres>), Create (<nom de la classe>), etc.

Cycle de représentation

représente
Classe-abstraction Classe-programme
(implémentation)
instanciation
Abstraction (Exécution)
(Analyse)

Occasionne
Objet du Objet

Monde réel informatique


Représente
c) Propriétés d’une classe
Les caractéristiques constitutives d’une classe se décomposent en :
 Propriétés informatives (caractéristiques statiques : stockage d’informations
(attributs, champs, propriétés)).
 Propriétés actives (caractéristiques dynamiques : manipulation d’informations
(comportements, méthodes).
Les deux peuvent être portées par une classe, sur un objet, les premières vont valoriser, les
secondes sont déductives.

Page 9/23
Concepts de base de la programmation orientée objet
Définition : Les propriétés informatives fournissent des renseignements sur l’objet sans le
modifier.
Les propriétés actives déclenchent des traitements à l’intérieur de l’objet et décrivent ses
comportements. Elles provoquent soit la modification de l’objet dans son contenu ou dans son
état (actions sur les propriétés informatives), soit la satisfaction d’un service demandé par un
autre objet (envoi de messages à d’autres objets).
Cette définition appelle trois remarques :
1. L’expression « propriétés informative » est assez voisine de l’usage de « propriété » dans
les modèles conceptuels de données. Mais elle recouvre également des propriétés
calculées qui ne doivent pas figurer sur un modèle de données.
Exemple : Classe ARTICLE
TVA et Prix HT sont des propriétés informatives.
En effet, les propriétés sont des éléments du méta modèle utilisé pour l’analyse, i.e. que
les considérations d’implémentation (données ou traitements) n’ont pas cours, seuls les
services attendus de la classe importe. En conséquence, il n’y a pas de raison de
représenter différemment la TVA et le Prix HT.
2. Cet élargissement de la notion de propriété augmente la capacité de représentation au
point que le modèle objet évoque naturellement les vues externes, i.e. la vision de
l’utilisateur.
3. L’exemple précédent risque de surprendre les personnes familières de l’orienter objet.
Elles ont pris l’habitude de distinguer les attributs (champs, données, variables) et les
méthodes (fonctions ou procédures sur la classe). Dans leur esprit, la propriété Prix HT est,
sans nul doute possible, un attribut qui contiendra une valeur pour l’objet, valeur
irréductible à tout traitement. Par contre, la TVA est implémentée comme une méthode
puisqu’elle exige un calcul.

« Propriété informative » et « Propriété active » appartiennent au vocabulaire de l’analyse.


« Attribut » et « Méthode » appartiennent au vocabulaire de la programmation.
Les deux activités répondent à des préoccupations différentes, il est normal de distinguer leurs
matériaux de base.

Remarques
1. Une propriété informative peut se traduire dans le logiciel par une méthode. L’exemple de
la TVA en dit long.
2. Une propriété active peut s’exprimer par un attribut (cas très rares). Par exemple, les
primes à payer à un employé. Ces primes sont présentées par le comptable comme le
résultat d’un traitement, impliquant plusieurs règles de gestion et plusieurs informations
élémentaires sur l’individu ou son activité pendant le mois, sur les résultats de l’entreprise,
etc… Pourtant on peut très bien construire le système informatique de telle façon que le
montant des primes soit actualisé à chaque évènement significatif, du genre : MR BAZOR
vient de signer un contrat avec la société TANTANPION, on lui ajoute 100 000 FCFA sur sa
prime mensuelle. Dans ce cas de figure, on a remplacé un traitement par un attribut.
Mais il est vrai que le traitement ne disparait pas pour autant. Son contenu est simplement réparti
différemment à travers le logiciel, et probablement sous formes d’instructions incluses à des
méthodes de l’objet BAZOR et des objets impliqués dans la vente. Cette solution parait-elle
artificielle ? c’est vrai qu’à repartir la matière d’un même traitement à travers plusieurs unités
logicielles, on peut craindre des difficultés de maitrise. Pourtant, il se trouve des contextes ou
cette solution simplifie grandement la réalisation. De façon générale, elle est préférable à chaque
Page 10/23
Concepts de base de la programmation orientée objet
fois qu’un traitement requiert l’information issue de différents évènements du système : une telle
solution est d’ailleurs conforme à l’esprit orienté objet.

d) Encapsulation

L’encapsulation est le mécanisme par lequel le développeur cache une partie de l’information
pour préserver l’intégrité de l’objet. Ce faisant, il établit une séparation entre une
interface(publique) et une implémentation(invisible).
C’est en recourant à l’encapsulation que le développeur produit ces objets protégés, surs, dont il
peut garantir la cohérence et le respect des règles de gestion.
Pour supporter l’encapsulation, le paradigme objet prévoit :
- L’association des attributs et des méthodes : une information soumise à une contrainte ne
sera mise à jour que par une méthode dans laquelle on aura programmé la condition à
vérifier ;
- Des clauses de visibilité permettant de protéger un attribut (lecture, écriture) ;
- La séparation entre l’interface (parfois appelé spécification) et l’implémentation (privée,
invisible et inaccessible de l’extérieur de l’objet).
Ces dispositifs forment ce qu’on appelle le masquage de l’information.

2.2.3 Classification
Par l’abstraction, le modélisateur dégage des classes qu’il décrit par leurs propriétés. Mais le
raisonnement ne s’arrête pas là. Il ordonne les classes entre elle par deux mouvements
contraires.
2.2.3.1 Généralisation et spécification
Premier mouvement, il compare entre elle les classes reconnues i.e. qu’il confronte leur
définition : définition structurelle (les propriétés des classes) et définition fonctionnelle (l’usage
des classes). Ce faisant, il arrive qu’il relève des similitudes, signes de parenté ou de
regroupement possible. Ce mouvement est la généralisation.
L’autre mouvement procède à l’inverse. A partir d’une définition de classe, le modélisateur
découvre des cas particuliers, des accidents, des considérations nouvelles qui, par leur précision,
font éclater le cadre initial. Cela amène à définir de nouvelles classes (sous classes) qui, tout en
respectant la définition de la première (la surclasse ou super-classe), portent des propriétés
nouvelles ou différentes. Ce mouvement est la spécialisation.
La généralisation et la spécialisation se combinent pour élaborer une structure des classes
représentant les rapports ascendant/descendant (surclasse/ sous-classe), classe mère/classe fille.
C’est ce qu’on appelle la classification.
Dans son effort de classification, le modélisateur recourt le plus souvent aux deux types de
définition : compréhension et extension.
La définition en extension enclenche plus souvent la spécialisation car elle révèle dans les
manifestations du concept les particularismes inattendus.
La définition en compréhension (ou en intention) incite plutôt la généralisation car, se
concentrant sur le concept même, elle prolonge l’abstraction et exhume des classes plus
abstraites, de portée générale.

a) Héritage
La classification comme opération intellectuelle, est au fondement de toute démarche
scientifique et de toute appréhension rationnelle du réel.

Page 11/23
Concepts de base de la programmation orientée objet
Définition : L’héritage est le procédé par lequel une classe, dite sous classe, reçoit une partie de
sa définition d’une autre classe, dite super-classe. Ce procédé restitue au sein du logiciel
l’activité intellectuelle de classification.
Selon les langages, l’héritage est simple (une seule classe mère) ou multiple (plusieurs super-
classes possible pour une classe). L’héritage multiple pose des problèmes que les méthodes
d’analyse-conception doivent prendre en compte : conflit d’héritage.
Dans un modèle de données de type entités-relations, le lien logique d’héritage se traduit par une
relation « est un » ou « est une sorte de » par rapport à cette façon de faire, le modèle objet
présente les avantages suivants :
o Il n’est pas besoin de formuler des contraintes d’intégrité pour exprimer l’exclusion ou la
partition.
o Il n’est pas besoin de nommer la relation (ce qui complique dans un modèle entités-
relations si on respecte la consigne suivant laquelle les relations ne doivent pas porter les
mêmes noms).
o L’héritage dans un modèle objet porte sur les propriétés actives (comportements) comme
sur les propriétés informatives, alors qu’un modèle des données ne montre qu’un sous-
ensemble des propriétés informatives (propriétés statiques et irréductibles) et que le
modèle des traitements ne modélise pas en termes de propriétés actives. Ainsi le modèle
objet produit des modèles en général plus élégants, moins chargés.

Lien de l’héritage

Selon Merise En orienté objet (formalisme OMT)

INDIVIDU
INDIVIDU

0 ,1

0,1 0,1

R1 est une R2 est une


sorte1,1
de sorte de HOMME LIBRE ESCLAVE

1,1 1,1

CIF
ESCLAVE
HOMME LIBRE

CIF : Contrainte d’intégrité fonctionnelle indiquant l’exclusion : « un individu est nécessairement


libre ou esclave ».
b) Héritage des propriétés, surcharge
Nous avons envisagé jusqu’ici l’héritage sous l’angle de l’ordonnancement des classes dans la
relation d’ensembles à sous-ensembles, i.e. sous l’angle de la classification.
Page 12/23
Concepts de base de la programmation orientée objet
Dire qu’une classe B hérite d’une classe A veut dire que les propriétés de A sont les propriétés de
B. L’existence de la classe B se justifie par l’une ou l’autre de ces raisons (ou les deux) :
o La définition structurelle de B comporte de nouvelles propriétés qu’ignore la classe A (c’est
que la définition fonctionnelle de B est plus précise ou plus riche et que son extension est
plus réduite).
o Au moins une des propriétés de A est redéfinie sur B.
Exemple classique : Classe Figure géométrique
La méthode Périmètre () est définie
différemment sur les classes Rectangle, Triangle,
Ellipse qui hérite de la classe Figure géométrique et qui
Périmètre ()
en plus reçoivent d’elle des propriétés comme la position,
la couleur (propriétés informatives) et la possibilité d’être déplacée, agrandie, mise en avant-plan
(propriétés actives).
Malgré la différence dans le procédé du calcul du périmètre, les objets des sous-classes sont
reconnus comme des figures géométriques, conceptuellement cette différence ne change rien a la
pertinence de la classification.
En réponse à ce besoin de particulariser des propriétés, les langages orientés objet offrent le
mécanisme de la surcharge.

Définition : La surcharge est le procédé (de modélisation et de programmation) par lequel on


redéfinit sur une classe une propriété héritée.

La surcharge est surtout utile pour les méthodes. Elle soulève des différences sur les attributs.
Tous les langages objet ne la proposent pas sur les attributs.
En reprenant l’exemple précédent, la classe carré hérite de la classe rectangle car carré est un cas
particulier de rectangle. (On pourrait faire hériter carré directement de figure géométrique, ce qui
éviterait par exemple de conserver sur carré les deux attributs longueur et largeur)
Ce qui définit le carré par rapport au rectangle, c’est la contrainte « longueur et largeur » qui
devra être modifiée lors de chaque vérification de l’objet. La méthode « périmètre » pour le carré
vas être spécifiée comme retournant la valeur 4*longueur. Cette spécification surcharge celle
exprimée dans la classe rectangle.
Que penser de la méthode « périmètre » de la classe figure géométrique ?
Qui pourra la spécifier facilement ? cette méthode restera non définie, en attente de la définition
pour les sous-classes. On dit d’une telle méthode qu’elle est virtuelle.
Une classe possédant une méthode virtuelle n’est pas instanciable. On la dit classe abstraite.

2.2.3.2 Généricité, Polymorphisme, liaison dynamique


A quoi sert une méthode virtuelle ?
Imaginons un instant que nous disposons d’une liste de figures géométriques : une structure que
nous aurions déclarée en langage objet par une syntaxe comme : liste : List(figure).
Caque objet dans cette liste a été instancié à partir d’une des sous-classes, par exemple :
FIG1=New (Rectangle)
ADD FIG1 IN liste
FIG2=New (Carré) Sur chacun de ces objets, l’on peut appliquer toutes les propriétés de la
classe Figure géométrique. L’on peut par exemple rechercher la figure
ADD FIG2 IN liste
dont le périmètre est le plus long, cela en parcourant les objets dans la
FIG3=New (Triangle)
liste et en activant la méthode périmètre sans se demander si l’objet
ADD FIG3 IN liste
manipulé appartient à telle ou telle classe.

Page 13/23
Concepts de base de la programmation orientée objet
En langage classique, on n’aurait pas pu faire l’économie s’une structure optative telle que :
Fig=<élément dans liste>
AVEC fig
SELON type_figure
Rectangle : p= périmètre_rectangle (L,l)
Carré p= périmètre_carré(L)
Triangle : p=périmètre_triangle(a,b,c)
Etc.
FIN SELON
FIN AVEC
En langage objet, d’une part on omet la variable type_figure, d’autre part, à la place de la
structure optative on écrit :
Fig=<élément de la liste>
P=fig.périmètre

NB : Une méthode est programmée de telle façon qu’elle exploite les attributs définis pour sa
classe, il est donc inutile de lui passer des paramètres.
Cette manipulation « générique » des objets Figure géométrique est possible parce que la classe
générique mentionne la méthode « périmètre » même si elle est virtuelle i.e. non défini à ce
niveau. La surcharge des méthodes se pratique également sur une méthode implémentée dans la
super-classe. La méthode « périmètre » aurait bien pu être définie sur la classe Figure
géométrique pour mesurer n’importe quel type de figures. Les méthodes des sous-classes
l’auraient alors surchargée dans un souci d’optimisation.
Une manipulation d’instances des classes différentes à travers des méthodes de même protocole
(nom et arguments) est un exemple de polymorphisme. Ce procédé est soutenu par la résolution
tardive ou la liaison dynamique.

Définition : La liaison dynamique est le mécanisme par lequel le choix de la méthode à activer
s’effectue non pas statiquement lors de la compilation, mais dynamiquement lors de
l’exécution.

Exemple : fig.périmètre : La méthode périmètre à activer ne sera connue qu’à l’exécution et non à
la compilation car elle tient compte de la nature de l’objet sur lequel elle s’applique.
Une règle pratique guide le modélisateur dans sa recherche en vue de dégager les classes et de
construire l’arbre d’héritage : la factorisation.

Définition : La factorisation est le procédé qui consiste à isoler une spécification de façon à ce
qu’elle soit partagée par plusieurs classes.
Ainsi si une propriété ou une portion de code apparait en divers endroits, on évite la redondance
en l’inscrivant dans une super-classe, éventuellement créée à cet effet et qui restera classe
abstraite.

2.2.4 Agrégation
Comme l’abstraction, l’agrégation concourt à la factorisation. Au niveau conceptuel, on peut
parler d’agrégation ou composition en tant que procédés de modélisation ou représentation ; le
terme assemblage est réservée pour la solution physique.
Définition : Un lien d’agrégation se définit comme une relation de composé à composant.
C’est avant tout une relation, et on hésite au cours d’une modélisation, entre une relation
ordinaire (nommée, devenant connexion d’instances) d’une part, et un lien d’agrégation, d’autre
part.

Page 14/23
Concepts de base de la programmation orientée objet
NB : il faut réserver le lien d’assemblage au cas où la dépendance sémantique entre les objets
reliés apparait suffisamment forte et évidente pour ne nécessiter aucun commentaire. Dans le cas
contraire, une connexion d’instances est préférable puisqu’elle oblige le modélisateur à exprimer
la nature du lien, son contexte et ses modalités (notion de méthode activée sur l’objet cible), de
rôles dans la relation, éventuellement qualification de la relation ou valorisation (relation
porteuse).

2.2.5 Coopération
Les trois principes d’intelligibilité sous-formulés, abstraction, classification et agrégation,
collaborent pour donner un modèle statique de la réalité. Par eux, l’analyse-concepteur recense
les concepts présents dans l’univers du discours, et exprime la signification impliquée. Ils inspirent
une représentation synchronique.
Différences entre les deux approches d’analyse
Approche fonctionnelle Approche orientée objet
Fonction : critère de perception Fonction : critère de pertinence
Unité : sous-fonction Unité : classe ou objet
La fonction se décompose en sous-fonctions. La fonction finalise la classe.

NB : il faut souligner que dans l’analyse, il faudrait toujours veiller à ce que les grandes fonctions
décrites dans le cahier de charges se retrouvent dans le développement.
Le rapport de la fonction globale à la classe n’est pas un rapport de détermination ou de
décomposition, mais un rapport de finalisation, si on veut bien s’autoriser ce barbarisme en lui
gardant le seul sens qu’il peut avoir au vu de l’étymologie : action d’imposer une finalité.
C’est ainsi qu’il faut comprendre le critère de pertinence :
o La pertinence s’évalue par rapport à un besoin
o Le besoin s’exprime en termes de fonctions (dans le cahier de charges ou la demande de
service)

la définition d’une classe est pertinente si elle concourt aux fonctions demandées et à rien
d’autre i.e. si sa finalité s’inscrit dans le fonctionnement général.
Ce critère s’applique non seulement pour déterminer si une classe candidate a droit à l’existence
ou pas, mais également pour borner la définition structurelle des classes (intérêt des propriétés en
regard de la finalité). Il s’élargit dès lors qu’on considère comme une fonction du système les
possibilités d’évolution et de capitalisation.

Afin d’éviter la confusion entre ces deux applications de la notion de fonction, on distingue :

o Fonction pour la signification globale


o Service pour la signification locale

Définition : - Une fonction, au sens informatique, est une activité de traitements en vue de
l’obtention d’un résultat ou de la satisfaction d’un besoin général
- Un service, au sens approche orientée objet, et dont il est considéré comme
responsable.

La notion de service appartient à la métaphore client/fournisseur très éclairante pour comprendre


les rapports entre les objets. Un objet A, pour parvenir à ses fins, demande un service à un objet B
: sous certaines conditions prédéfinies et dans le respect du contexte que A décrit à travers cette
relation, A joue un rôle de client, B celui du fournisseur. Les conditions et le contexte forment le
Page 15/23
Concepts de base de la programmation orientée objet
contrat, assorti de garanties à savoir : la fourniture du service si certaines conditions sont
respectées, ainsi que l’état du fournisseur (intégrité, invariants de classe, …)

Définition : Le principe de coopération inspire la modélisation orientée objet pour rendre


compte des relations entre les objets. Il se formule par la métaphore client/fournisseur selon
laquelle un objet sous – traite une partie de son activité en demandant des services à d’autres
objets.
Remarques
1. Il s’agit d’un principe d’intelligibilité car son application enrichit et valide la définition des classes
2. Il conduit le modélisateur à se pencher sur les aspects dynamiques du système
3. 3. Il complète le paradigme objet en fournissant le moyen d’adjoindre aux vues ontologiques et
structurelles (obtenues par l’abstraction et la classification), des éléments de définition
fonctionnelle : service (fonction locale), contrat, responsabilité, garantie.
Selon le principe de coopération, un programme orienté objet est vu comme un lieu où les objets
collaborent, se parlent pour obtenir les uns des autres des services qui leur permettent de réaliser
leur objectif, d’assumer leur responsabilité.
La traduction technique de la coopération consiste en l’envoi de messages.
Définition : L’envoi des messages est le mode d’échange entre les objets. Il aboutit à l’activation
d’une méthode selon un protocole prédéfini.
Un message est une structure qu’on peut décrire formellement comme suit :
MESSAGE = <objet destinataire, méthode à exécuter, arguments>
Les arguments sont les valeurs passées en paramètres à la méthode activée.

Dans l’exemple suivant, l’objet Client délègue à l’objet Compte la gestion du compte, sans que cela
soit perçu par les objets qui s’adressent à Client :
1. Client.déposer Somme
 Envoi message <COMPTE, CREDITER, Somme>
Compte. Créditer Somme
 Compte.Solde = Compte.Solde + Somme

2. Client.Connaitre Solde
 Sur tous les comptes de Client envoi message <COMPTE, DONNERSOLDE>
Compte.Donner Solde
 Retourne solde
Un objet, un programme ou l’utilisateur qui intervient sur l’objet Client n’a pas à connaitre les
objets délégués qui, comme Compte l’aident à parvenir à ses fins. L’envoi des messages agit donc
pour la maitrise du couplage.

L’envoi des messages a pour corrélats :


- La relation, telle que définie dans un modèle entités-relations,
- La connexion d’instances, qu’on peut définir comme une occurrence d’une relation entre
deux classes.

Page 16/23
Concepts de base de la programmation orientée objet
2.2.6 La réification
Les quatre principes d’intelligibilité forment le socle du paradigme orienté objet. Tout le reste en
découle, et particulièrement les deux principes opératoires.
Les principes opératoires répondent à une nécessité pratique : traduire en actes les principes
intellectuels, guider l’action dans le respect des prémisses. C’est pourquoi les principes opératoires
se déduisent naturellement des principes d’intelligibilité. En passant des principes d’intelligibilité
aux principes opératoires, l’on glisse de l’approche à la démarche. Comme il se doit, le premier
principe pratique de la démarche orientée objet réglemente le passage du réel à l’objet modélisé,
la décision de faire de quelque chose un objet.

Définition : Principe de réification pragmatique

<<Si l’on parle de quelque chose en lui attribuant des propriétés, ou si cette chose doit être
manipulée, alors il faut la représenter sous forme d’objet>> Jacques FERBER, Conception et
Programmation par Objets.

Les principes d’intelligibilité éclairent la pratique de la réification. Car il faut souvent aller au-delà
de l’évidence, et les slogans selon lesquels il suffit de piocher les objets naturels dans la réalité ne
conviennent pas à tous les contextes. D’autres considérations interviennent, telles la localité et la
factorisation.

2.2.6.1 Localité
Penser <<local>>, c’est respecter l’encapsulation.
<<Il faut penser à demander aux objets d’accomplir eux-mêmes leurs actions, et non chercher à
manipuler directement ces objets au loin par l’intermédiaire des procédures globales >>.

Exemple : Traitement de la paie


Le traitement ne sera pas conçu comme un programme appelant les objets Employé pour
manipuler leurs attributs, mais se réduira à une requête qui déclenchera la méthode
« calculer_paie » sur chaque objet.

Exemple : SELECT Employé.Calculer_paie FROM <table> WHERE <condition>.


Cette requête est valable dans les SGBDOO (SGBD Orienté Objet)
La localité associée au polymorphisme débarrasse les programmes de la plupart des structures
opératoires qui les alourdissent.

2.2.6.2 Factorisation
Par la classification et l’agrégation, on est amené à partager des propriétés entre plusieurs classes.
Cela nous met sur la voie des composants logiciels.
La factorisation doit agir comme une idée fixe, et influencer en permanence la réification. En
pensant factorisation, le modélisateur est conduit à isoler du sens et à construire des classes qui
n’affleuraient pas dans le matériau brut. Notamment, il élabore maintes classes abstraites qui
n’ont pas de sens immédiat dans l’univers du discours.

Remarque : Si une classe agit sur deux classes A et B, dans les mêmes conditions et selon le même
protocole, c’est que A et B appartiennent à un sur-ensemble dont il faut dégager la signification.
Exemple : Gestion commerciale
- Classes : Clients et Prospects (propriétés différentes sur les deux classes)
- Classe Action commerciale pouvant agir sur Clients et sur Prospects.

Création d'une classe abstraite Potentiel client dont héritent leurs deux premières.

Page 17/23
Concepts de base de la programmation orientée objet
Dans ce raisonnement, ce ne sont ni les attributs, ni les méthodes qui poussent à la factorisation,
mais une relation : on factorise une structure de contrôle.

2.2.7 Structuration du logiciel


Le principe de structuration rend compte des conséquences des notions objet sur le logiciel. Il
s’agit à peine d’un principe pratique ; on serait tenté de le nommer principe passif tant il découle
mécaniquement des solutions apportées par la technologie objet dans la droite ligne des quatre
principes d’intelligibilité.
Que trouvons-nous dans un système applicatif développé selon les techniciens orientées objet ?
- Les classes, unités minimales de source. Ce sont les « classes-programmes » qui
implémentent les «classes abstractions». Elles s’organisent en bibliothèques.
- Les programmes, car, nos objets, il faut bien les mettre en situation, les démarrer dans une
application bien conçue, les programmes se réduisent à :
o appel de bibliothèques dans lesquelles se trouvent les classes utiles
o déclaration d’une poignée d’objets
o activation d’une de leur méthode pour initier la coopération.
Les mêmes classes peuvent être utilisées par plusieurs programmes. Il y a tout dans le paradigme
objet pour atteindre la modularité. (Voir Bertrand MEYER, Conception et Programmation par
objets).

2.3. Le paradigme et la complexité


Un paradigme contient les règles selon lesquelles le réel va être perçu, ce que l’on appelle les
principes d’intelligibilité. Il oriente la représentation du réel que le développeur élabore au cours
de la modélisation.
Etudier la complexité dans son rapport à un paradigme entraine dans deux directions :
- D’une part le paradigme conditionnant la représentation, fournit un outil plus ou moins efficace
pour appréhender et exprimer la complexité du monde réel.
- D’autre part le paradigme ordonnateur du perçu produit plus ou moins de complexité dans le
monde réel donc dans le système logiciel

Donc paradigme  appréhension du réel représentation complexité

2.3.1 Approche de la complexité


La complexité est la propriété d’une entité composée de plusieurs éléments reliés entre eux. Elle
évoque la difficulté de maitrise, et est devenue un des grands sujets de la pensée postmoderne. En
informatique, la complexité a été analysée en couplage et cohérence. Un logiciel de qualité se
compose d’entités (modules, programmes, …) fortement cohérentes et faiblement couplées c’est-
à-dire que les entités ne traitent que d’un nombre restreint de concepts, et qu’elles limitent au
minimum les échanges entre elles.
Le paradigme classique intègre ces deux notions mais ne les applique qu’aux traitements, encore
qu’elles aient un sens pour un modèle de données. Sur un modèle de données, le couplage se
mesure par le rapport entre le nombre de relations et le nombre d’individus. La cohérence
exprime la pureté sémantique du modèle qui est dans un rapport inverse avec le couplage. Sur un
modèle des traitements ou un diagramme des modules-programmes, cohérence et couplage sont
plus indépendants. En général, ils progressent solidairement : un module faiblement couplé
contient la matière de plusieurs concepts, donc échange davantage avec les autres modules la
structure présente un fort couplage. L’analyse de la complexité doit le plus souvent être menée
avant la séparation données/traitements

Page 18/23
Concepts de base de la programmation orientée objet
L’on doit appliquer des notions de cohérence et de couplage sur les significations même. Dans
l’usage courant, le terme complexité connote deux composants :la structure et le sens. Une chose
est complexe quand on n’arrive pas à démêler les relations entre ses composants. Une chose est
complexe aussi quand son sens est difficile à percevoir.
Cette division entre structure et sens reproduit celle entre couplage et cohérence. Ce changement
de vocabulaire induit le passage d’une approche fonctionnelle à une approche sémiologique ;
laquelle se révèle plus féconde.

Définition

1-Dépendances structurelles : deux structures se relient et s’échangent de


l’information (données, commandes). Il y a une dépendance structurelle dès lors
qu’une classe nomme ou déclare une autre classe.

2-Dépendances sémantiques : une entité dépend logiquement d’une autre pour se


réaliser, ou qu’elle ne fait sens qu’en coopérant avec une autre.

La situation idéale se présente quand toute dépendance structurelle exprime totalement et


exclusivement une dépendance sémantique.

2.3.2 Cohérence
Elle peut se définir en deux formules :
-formule faible : tout ce qui se trouve sous une entité se rapporte à un même
concept.
-formule forte : tout ce qui se rapporte à un même concept se range sous une
même entité.
Le paradigme classique parvient à appliquer la formule faible, mais échoue à réaliser la formule
forte

Exemple : Le numéro de sécurité sociale est une propriété portée par l’entité Personne. Il obéit à
une syntaxe précise (premiers caractères pour le sexe, puis année de naissance, etc.)
Dans une application à chaque fois qu’on manipule ce numéro, il faut en contrôler la syntaxe.
 Ecriture d’une routine afin de limiter la duplication du code. L’appel de cette routine est sous la
responsabilité de chacun des programmes utilisant le numéro. Une telle routine étant séparée de
l’entité Personne, il faudra lui passer en paramètres toutes les informations nécessaires. Donc la
dépendance sémantique entre le numéro de sécurité sociale et les autres propriétés de l’entité
n’est pas localisée ni garantie. Une telle dépendance trahit une redondance dont on doit
débarrasser un modèle entité-relations.
Plus généralement, dans la programmation classique, il y a dissociation entre les propriétés et les
règles qui les contraignent. La programmation orienté objet résout ce problème grâce à
l’encapsulation. Par une bonne encapsulation et une application du principe de localité, le
développeur a la ressource de préserver la cohérence dans ses deux formules, faible et forte.
Le numéro de sécurité sociale ne serait manipulé qu’à travers une méthode chargée de contrôler
la syntaxe. La dépendance sémantique serait donc exprimée dans la classe Personne, une seule
fois et avec la garantie qu’elle sera toujours vérifiée, quelles que soient les actions que subit
l’objet.
La cohérence des classes s’évalue en considérant la liste des propriétés, mais aussi le contenu des
méthodes. Une méthode ne doit, en principe réaliser elle-même des opérations sur d’autres
objets que celui auquel elle appartient. Elle peut seulement, par envoi des messages, activer des
méthodes sur d’autres objets.
Page 19/23
Concepts de base de la programmation orientée objet
La cohérence a partie liée aussi avec l’héritage. Sur l’arbre d’héritage, si une propriété apparait sur
toutes les classes d’un même niveau, on peut la remonter au niveau supérieur, éventuellement au
prix de quelques surcharges.

2.3.3 Couplage
Le couplage est nécessaire. Le principe de coopération le prouve. Cependant il doit être limité au
strict minimum. Cela amène parfois à redessiner les classes. La programmation objet aide à
maitriser le couplage encore une fois par encapsulation et par spécification des interfaces. Les
objets ne communiquent qu’entre eux qu’à travers leur interface et par envoi de messages. En
outre la conception orientée objet s’appuie sur les notions de contrat, garantie et responsabilité
qui favorisent la compréhension des échanges entre objets. Les langages orientés objet apportent
un éventail plus riche de dépendances structurelles sur lesquelles le développeur doit jouer afin
d’exprimer la gradation des liens sémantiques. Par ordre décroissant des forces, les dépendances
structurelles sont :
-dépendance de classe à classe : elle traduit une dépendance sémantique entre
concepts et s’exprime par le lien d’héritage.
-dépendance de la propriété à la classe :la dépendance la plus solide, incassable. Toute
signification fortement liée à un concept s’exprime par une propriété sur la classe qui
traduit le concept. L’élargissement de la notion de propriété (informative ou active,
attribut ou méthode) permet de pousser très loin ce précepte. En plus, l’application
des attributs de visibilité (public/privé, lecture/mise à jour) sur les propriétés enrichit
encore l’expression des dépendances.

Exemple : Un attribut dépend fortement du contexte de l’objet ; ou le rend donc privé et ne sera
accessible que par une méthode (accesseur) qui renverra sa valeur après contrôle du contexte.
 dépendance de la règle de gestion à la classe ou aux propriétés : la règle est souvent immergée
dans les méthodes comme dans l’exemple du numéro de sécurité sociale. La dépendance est,
moins forte que celle de la propriété à la classe, non pas qu’elle exprime une dépendance
sémantique plus faible, mais parce qu’une mauvaise programmation peut l’omettre en laissant un
accès à une propriété sans que la règle soit déclenchée.
 dépendance d’objet à objet- lien d’assemblage :
Plus faible que les précédentes car la référence à l’objet composant peut ne pas être
renseignée. Elle traduit cependant une dépendance sémantique forte.
 dépendance objet à objet – connexion stable :
C’est la connexion d’instances exprimant une relation de signification. Comme le lien
d’assemblage, elle s’implémente par une référence d’objet parmi les attributs de la classe.
 dépendance objet à objet – connexion provisoire : c’est aussi une connexion d’instances mais
invisible dans l’interface de la classe. Elle s’établit à l’intérieur d’une méthode pour un besoin
ponctuel et disparait aussitôt la méthode terminée.

Page 20/23
Concepts de base de la programmation orientée objet
Exemple : L’exemple suivant montre plusieurs dépendances structurelles. Le formalisme utilisé est
OMT mais les cardinalisés sont placées comme en Merise (du côté du sujet de la relation)

CLIENT 1,n 1,1 COMPTE


Nom NO compte
Solde DEVISE
Unité
Valeur
Ouvrir
Apporter_devise
(Montant, unité)

ADRESSE

COMPTE
COMPTE EPARGNE
COURANT

Cet exemple montre plusieurs dépendances structurelles :


 Classe CLIENT et classe ADRESSE : lien d’assemblage
 Classe CLIENT et classe COMPTE : connexion stable(d’instances)
Cette relation est stable puisqu’elle persiste après la fin de l’exécution
 Classe COMPTE et classe DEVISE : connexion provisoire

Plus précisément, cette connexion existe entre la méthode apporter_devise et la classe


DEVISE. Elle s’établit provisoirement pour que cette méthode puisse convertir les devises
reçues et les verser sur le compte. Valeur peut être une méthode qui déclenche une
consultation à distance pour obtenir le renseignement.
 La classe COMPTE se spécialise en compte courant et compte épargne. Le numéro de
compte dépend du type de compte

La règle syntaxique qui porte sur le numéro est programmée dans la méthode ouvrir.
En pseudo-code on pourrait avoir :
Classe CLIENT
Nom : X (30)
ad : Adresse
cpt : Liste(compte)
Fin Classe CLIENT

Page 21/23
Concepts de base de la programmation orientée objet
Classe COMPTE
Interface

Numéro : 9(12)
Solde : 9(12..2) lecture seule
Ouvrir
Apporter_devise (montant : 9(6), u : X)
Implémentation

Num_compte : 9(12) méthode virtuelle


Ouvrir
Numéro : num_cpte
Solde : 0
-------
Enregistrer
Fin ouvrir
Apporter_devise
dev :DEVISE
SELECT valeur from DEVISE in val WHERE unite = u
Solde = solde +montant*val
Fin apporter_devise
Fin Classe COMPTE

Classe CPTE_COURANT hérite de COMPTE


Implémentation

Num_cpte
<préfixe désignant le type de compte>
<rechercher dernier numéro dans ce type>
<retourner la valeur obtenue>
Fin num_cpte
Fin Classe CPTE_COURANT

Remarques
 Ce pseudo-code ne distingue pas le lien d’assemblage de la connexion d’instances. Les deux sont
traduits par une référence d’objets. Cela est un peu regrettable car la distinction aurait permis de
traiter la persistance plus naturellement. Quand on enregistre un client il est évident que l’on
désire enregistrer également les informations portées sur Adresse et plus généralement sur les
objets agrégés (composants de) CLIENT. Il n’n va pas de même avec les objets en relation
(connexion d’instances)
 La cardinalité (1, n) de CLIENT vers COMPTE a été transcrite dans ce cas par une liste de références
d’objets
 La relation d’utilisation entre COMPTE et DEVISE s’obtient par une déclaration d’objet dans la
méthode <<apporter_devise>> et une recherche de l’objet approprié.
 La méthode <<num_cpte>> n’appartient qu’à l’implémentation de la Classe COMPTE ; elle n’est
donc pas visible de l’extérieur. Son intérêt est d’isoler la partie spécifique de la méthode
<<ouvrir>>. Mais le fait qu’elle soit portée par la super-classe permet de localiser la dépendance
sémantique qui existe entre cette méthode et le numéro de compte.

Page 22/23
Concepts de base de la programmation orientée objet
2.3.4 Entropie
L’entropie mesure la dégradation du logiciel. Elle ne peut que croitre à moins d’une grande
dépendance d’énergie pour maintenir, établir ou augmenter d’ordre : test de non régression,
maintenance perfective, …etc.
En programmation classique, une intervention sur le logiciel risque toujours de se propager à
travers tout le système applicatif. Cela tient à l’éparpillement du sens. Si le format d’une donnée
ou une règle de gestion change, c’est à travers tout le projet qu’il faut analyser l’impact, traquer
les conséquences et on en oublie toujours. En programmation orientée objet, la propagation des
modifications se limitent le plus souvent à la classe, au pire à son entourage immédiat. Ce qui peut
arriver de plus grave, c’est de modifier la signature d’une méthode (nom, type de son résultat,
liste des arguments et format)

2.3.5 Perception
Dans les paragraphes précédents, on a envisagé la maitrise de la complexité sous l’angle du
matériau logiciel. Il est une autre perspective également importante celle de la perception, de
l’appréhension de la complexité par l’esprit humain.
La maitrise de la complexité repose ici sur deux piliers :
la possibilité d’accéder à une vision globale et à des vues intermédiaires selon le niveau du
problème à traiter
le maintien de l’intégrité de chaque vue
Les vues adéquates s’obtiennent par la combinaison de deux procédés : l’abstraction qui permet
de rassembler une portion de réalité sous un concept ; l’effet de zoom qui focalise sur le niveau de
détails requis

Page 23/23

Vous aimerez peut-être aussi