AILES : Objet, Abstraction, Encapsulation & Information Hiding (Réponses)

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.

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.