|

Écrivez
à AILES ! |

Retour
vers programmation |

Retour
vers les questions Objet |

Retour vers les
questions sur
l'abstraction, l'encapsulation & l'information
hiding |
|
|
Questionnaire Objet
Abstraction, Encapsulation
& "Information Hiding"
(masquage
d'information)
[javaworld],
[toa],
[OOM-PP]
|
Franchement, j'ai toujours traduit
en anglais le fait de masquer de l'information par
"encapsulation". Quant à l'abstraction, cela
revenait aussi pour moi à masquer ou non de l'information.
D'ailleurs,
[OOM-PP] ne s'en cache
pas et considère, je cite : « While I accept these somewhat
pedantic distinctions I remain convinced that to blur them in
an introcdutory text of this nature will serve not to confuse
but to clarify » [«
Bien que j'accepte ces distinctions plutôt pointilleuses, je
reste convaincu que le fait de les confondre dans un texte
introductif de cette nature sert non à compliquer
les choses, mais à les clarifier. »]
De fait, ayant lu le "texte
introductif" de
[OOM-PP] et l'ayant trouvé
horriblement confus... j'ai préféré me pencher sur les
"distinctions tatillonnes" auxquelles il faisait
allusion. [javaworld] et [toa] m'ont pour cela bien aidé. |
Pour commencer, une remarque toute simple
et pourtant peu évidente : chacun des termes étudiés ici peut être
vu comme un processus ou une entité.
Abstraction :
[processus] extraction
des détails essentiels qui caractérisent un concept, tout en
ignorant les autres caractéristiques non essentielles.
[entité] une
abstraction représente l'ensemble des caractéristiques essentielles
d'un concept.
Ce qui est fascinant, c'est de constater que la
plupart des gens qui pense "abstraction" tendent à croire
que les caractéristiques non-essentielles se retrouvent cachées
(d'où "abstraction" = "information hiding") à
l'intérieur de la classe qui représente le concept (d'où
abstraction = encapsulation).
Mais non ! Puisqu'on vous dit que les
caractéristiques non-essentielles sont I-GNO-RÉES.
On ne les masque pas, on ne les encapsule pas : on s'en balance, on
s'en contre-fiche.
Si vous faîtes un logiciel dont le domaine
applicatif est "le calcul de vos impôts" (dire que j'écris
cela le 23 mars 2002, à 2 jours de la date limite de remise des
impôts!), vous allez abstraire du concept "contribuable"
des caractéristiques comme son âge, son adresse, sa situation
familiale, ses revenus (oui, surtout ses revenus... snif, et en €
s'il vous plaît), etc.
Ses autres caractéristiques comme ses croyances religieuses, sa
passion pour le jazz ou sa peur du vide passeront tout simplement à
la trappe.
Encapsulation
[processus] regroupement
de plusieurs items dans un container (physique ou logique).
[entité] container
ou package qui contient une ou plusieurs items.
Excusez-moi, mais où voyez-vous dans les
définitions ci-dessus la moindre allusion à :
- la visibilité associée au container ?
L'encapsulation serait du masquage d'information uniquement s'il
était opaque ou, pour parler C++, si les attributs que j'encapsulais
à l'intérieur d'une classe étaient privé. Or ils pourraient être
"public", et donc parfaitement visibles.
- la nature du container ? si je veux encapsuler les
"enfants" d'un contribuable (toujours en restant dans le
"trip" des impôts), je peux :
* déclarer une liste d'enfants (dont
je ne précise même pas encore l'implémentation : Vector, Array, etc);

* déclarer une relation qualifiée entre
"contribuable" et "enfant" afin de tenir compte
d'enfants issus de multiples mariages;

* déclarer une classe "Enfants"
qui pourrait même masquer entièrement le concept "Enfant"
et n'exposer que les services attendus par Contribuable (nombre
d'enfants, âge, ...) :

Dans les 2 premiers cas, "Enfant" se retrouve encapsulé
dans un structure qui peut être de très bas niveau (un tableau de
byte suffirait à implémenter un simple tableau). Mais alors il faut
bien connaître ses caractéristiques pour l'utiliser
("information hiding" est à son minimum)
Dans le dernier cas, il se retrouve encapsulé à l'intérieur d'une
"barrière conceptuelle", ici une classe "Enfants"
qui gère la liste
d'enfant comme elle l'entend.
Information hiding
[processus] rendre
visible uniquement les caractéristiques de conception stable d'un
concept.
[entité] ensemble
des caractéristiques dont la conception est difficile ou
potentiellement amené à changer.
Typiquement, un attribut est souvent
masqué par un accesseur qui renvoi la valeur sans révéler la
nature. (l'attribut "revenus" du Contribuable sera masqué
par l'accesseur getRevenus() afin de renvoyer la valeur en € de
l'ensemble de ses ressources financières, quelques soient leurs
natures, frauduleuse ou non ;) ! ) Il s'agit là d'une décision de
conception qui reconnaît l'existence d'un attribut
"déduit" (donc calculé à partir d'autres éléments).
De plus, il existe des degrés d'"information
hiding". Sans même parler d'accesseur, tout attribut peut, en
C++, se voir associer une visibilité qui va masquer
plus ou moins l'information (public, protected ou private). En java,
un attribut de visibilité "package" sera masqué de toute
classe extérieure au package... mais parfaitement visible pour toute
classe de même package.
Abstraction, Encapsulation & Information Hiding
Voici, pour résumer, un petit modèle UML qui précise les liens
existant entre ces 3 concepts.
Processus |
 |
L'abstraction produit des caractéristiques
abstraites d'un concept. Elles sont encapsulées et on y associe, pour ce container
conceptuel donné et une
abstraction donnée, une visibilité. |
Entités |
 |
Les informations qui caractérisent un concept
sont soit des abstractions, soit des informations ignorées
car n'entrant pas dans le point de vue choisi pour abstraire
le concept (point de vue qui illustre un domaine applicatif
précis).
Les entités encapsulées sont regroupées au sein d'un
container logique, avec une visibilité associée. Encore une
fois, le masquage d'information est un moyen supplémentaire
de raffiner une encapsulation. Celle-ci pourrait se faire sans
masquer aucune information. |
|