Ce chapitre a pour objet d'introduire la pratique d'encapsulation que, dans un premier temps, nous limiterons aux seuls attributs. Cette encapsulation pour les attributs est justifiée par la préservation de l'intégrité des objets, la lecture des attributs détachée du stockage et la stabilisation des codes.
Accès aux attributs d'un objet, accès externe aux attributs, pratiquement tous les langages de programmation OO, permettent, pour autant que l'on déclare explicitement les attributs comme public. Et nous voici en présence d'un nouveau mot-clé, capital de la programmation OO, qui caractérise l'accès aux attributs et au méthodes de la classe par toute autre classe. Ce mot-clé ne devrait idéalement prendre que deux valeurs : public et private.
Attribut private : Un attribut ou une méthode sera private, si l'on souhaite restreindre son accès à la seule classe dans laquelle il est déclaré. Il sera public si son accès est possible par, ou dans, toute autre classe.
En déclarant les attributs comme private, toute tentative d'accès direct, sera verbalisée par le compilateur. Ce mot-clé, private ou public, permet au compilateur de nous seconder, en faisant d'une mauvaise pratique orienté objet une erreur de syntaxe (et de compilation).
Encapsulation des attributs, si vous déclarez explicitement des attributs private, leur simple lecture ou modification se fera, à l'aide de méthode d'accès.
En C#, les modes d'accès , set et get, sont regroupés dans une seule méthode. Le mot-clé value indique à transmettre dans l'attribut. L'appel de la méthode se fait tout comme un accès direct à un attribut quelconque. Comme il s'agit, en effet, d'une forme « indirecte » d'accès à l'attribut, on conçois mieux l'existence de cette syntaxe.
Depuis sa troisième version, ce langage est encore plus audacieux, car il vous permet le raccourcis reproduit dans le code pour un attribut. Il n'est même plus besoin de déclarer l'attribut. Vous vous limitez à la seule méthode d'accès, c'est le compilateur qui se chargera,de la création et de la gestion de l'attribut en question. Comme cela, il est sûr que vous respecterez les mécanisme d'encapsulation.
class 01{
private int attribut1 ;
...
public int accesAttribut1 {
get{
return attribut1 ;
}
set{
attribut1 = value ;
}
public int Attribut2{
get ; set ; /* raccourcis reproduit dans le code pour un attribut */
}
}
}
Encapsulation : pourquoi faire ? Pour préserver des objets, tout d'abord pourquoi sommes-nous instamment priés de déclarer les attributs comme private? Un première raison étend la responsablilié des classes, non seulement au typage de leurs objets, mais également à la préservation de l'intégrité de ces derniers. En général, les objets d'un classe, décrits et caractérisés par la valeur de leur attributs, ne peuvent admettre que ces attributs prennent toute et n'importe quelle valeur. Pourtant, rien dans la déclaration même des attributs ne permets ces restrictions. Normalement tout programmeur est suffisamment malin et prévoyant pour deviner ce que l'on fera de ces attributs. Le programmeur de la classe elle-même, sans doute, mais pourquoi les programmeurs de toutes les autres classes, appelées à interagir avec la première, devraient-ils également se préoccuper de cette intégrité ?
Mieux vaut prévenir que guérir ... Un coup de paille lors de la compilation d'un programme est préférable à un coup de poutre à son exécution. Il vaut mieux ainsi, laisser à chaque classe, le soin de s'assurer qu'aucun de ses objets ne subira de changement d'état non admis. L'unique manière de procéder consiste à rendre les attributs inaccessibles, sinon par l'entremise de méthodes publiques, c'est à dire accessibles, elles et qui s'assureront que les nouvelles valeurs prises restent dans celles admises. Charité bien ordonnée commence par soi-même.
En quelque sorte, les méthodes de la classe filtrent l'usage que l'on fait des attributs de la classe. En entrée, elles ne toléreront que certaines valeurs. En sortie, elle présenteront les attributs, d'une manière qui convient aux autres classes, à celles qui veulent connaître leur valeur. C 'est ce que Bertrand Meyer tente d'installer d'une manière moins forcée dans sa version des langages OO, par l'introduction des notions d'invariance, par le fait qu'un objet puisse, avant d'exécuter une méthode, vérifier qu'un ensemble de préconditions soit satisfait et, qu'à l'issue de cette exécution, c'est un ensemble de post-condition qui le soit.
Intégrité des objets, une première raison justifiant l'encapsulation des attributs dans la classe est d'obliger cette dernière, par l'intermédiaire de ses méthodes, à se charger de préserver l'intégrité de tous ses objets
La gestion d'exceptions,toujours dans la perspective de sécuriser au maximum l’exécution des codes, toute tentative, lors de l'exécution du programme visant à violer l'intégrité d'un objet, fait l'objet d'un mécanisme de gestion d'exception. La gestion d'exception est un mécanisme de programmation assez sophistiqué, destiné à la réalisation de code plus robuste et qui permet d'anticiper et de gérer les problèmes pouvant survenir lors de l'exécution d'un code dans un contexte sur lequel le programmeur n'a pas tout contrôle.
Toute source de problèmes pouvant survenir à l'exécution n'est pas évitable, tel un réseau ou disque dur inaccessible, un processeur, inapte au multithreading, un accès incorrect à une base de données, un entier devant servir de diviseur égal à zéro et beaucoup d'autres. En général, les instructions susceptible de poser de tels problèmes sont placées dans un bloc try-catch. Lorsque le problème se pose effectivement, le programmeur est censé l'avoir anticipé et avoir prévu dans la partie catch du bloc une manière de récupérer la situation à ce stade. Sans cela, le code s'interrompt en déclenchant juste l'exception. En héritant de la classe Exception, le programmeur peut créer ses propres classes d'exception, en accord avec la logique de son code et de manière à bénéficier de ce mécanisme de gestion d'exception prêt à l'emploi.
Il apparaît donc assez cohérent de forcer le programmeur à en faire usage. Les exceptions sont définies dans une structure taxonomique, de la plus générique comme « Exeption », à la plus précise comme « FileNotFoundException ». Le « catch » tente d'abord d'attraper les exceptions les plus précises avant de se rabattre sur les plus génériques.
Pour cloisonner leur traitement, une deuxième justification à l'encapsulation des attributs, et partagée avec l'encapsulation de méthodes, est de renforcer la stabilité du logiciel à travers le temps et ses multiples et possible évolutions. Nous avons vu que la classe permet une décomposition naturelle du logiciel, en autant de modules à répartir entre plusieurs programmeurs, Afin que les travaux de chacun des programmeurs ne doivent faire l'objet de révision et d'adaptation, à chaque changement par l'un d'entre eux d'une partie de son code, il est extrêmement important de rendre les codes les plus indépendants possible entre eux. Il faut limiter l'impact dans le reste du code d'un quelconque changement dans une une petite partie de ce dernier.
En programmation OO toute modification d'une partie private de la classe n'aura aucun impact sur le reste du programme. Il est bien connu par les développeur de logiciel que la maintenance du code constitue une dépense, il est capital qu'un travail d'anticipation, concrétisé par l'encapsulation entraîne les programmeurs à séparer, dans les développement de leur classe, ce qui restera stable dans le temps(déclaration public) de ce qui est susceptible, encore, de possible modification (déclaration private).
Les attributs et leur typage sont de façon typique une partie de code susceptible de nombreuses évolutions dans le temps. Déjà, la manière même de sauvegarder l'état de l'objet sur le disque dur,risque d'être revue à travers le temps : sauvegarde en tant qu'objet, sauvegarde séparée des attributs dans un fichier ASCII, sauvegarde en tant qu'enregistrement d'une base de données relationnelle, sauvegarde dans une base de données orientée objet. Il devient alors capital, afin de neutraliser l'impact d'un tel changement, de déclarer comme private tout ce qui concerne le stockage des attributs. En effet seul le type de la lecture de l'attribut, et nullement la manière de le stocker ou le coder, devrait concerner toute autre classe désirant y avoir accès
Stabilisation de développements, il y a une seconde raison de déclarer les attributs comme private, commune aux méthodes : c'est d'éviter que tout changement dans le typage ou le stockage de ceux-ci ne se répercute sur les autres classes.
Aucun commentaire:
Enregistrer un commentaire