POURQUOI CE BLOG, POUR QUI ?


POURQUOI CE BLOG, POUR QUI ?
Ce Blog s'adresse à tous ceux qui sont passionnés par les sciences informatiques , Professionnels,Etudiants,Amateurs ...
Les sujets exposés dans la suite se rapporteront essentiellement sur l'analyse informatique,la programmation,le développement ainsi que à l'architecture IT.
QUI SUIS JE ?
Je suis Kangulungu Lubilanji, Consultant-Freelance sur les technologies .NET,C#,ASP.NET ... Contactez moi pour plus d'informations.

La Programmation OO: Chapitre 8. Les classes et leur jardin secret

Chapitre 8. Les classes et leur jardin secret.
Ce chapitre poursuit l'exposé de la pratique de l’encapsulation en l'étendant aux méthodes. Il sépare l'interface d'une classe de son implémentation. Il justifie cette encapsulation par la stabilisation des développements qu'elle améliore. Il discute les différents niveaux d'encapsulation rendus possibles dans les langages de programmation, il termine par une allusion aux systèmes complexes dont se rapproche tant la pratique de 'lOO et qui contribue à en permettre la maîtrise.

Encapsulation des méthodes, idéalement, même la simple lecture des attributs ne devrait que très rarement constituer le contenu de méthode publique. La raison en est simple. Les autres classes ont-elles jamais besoin de simplement lire les attributs d'une classe données ? Exceptionnellement. Le plus souvent, elles modifient ces attributs ou les utilisent à travers une méthode, afin qu'à partir de la valeur de ceux-ci, une nouvelle activité se déclenche, quitte à se propager de classes en classes. Simplement les lire, et rien d'autre, n'apparaîtra que très rarement utile. Cela nous amène naturellement à une nouvelle règle de bonne conduite OO.
Méthode private, en plus des attributs, une bonne partie des méthodes d'une classe doit être déclarée comme private.


Interface et implémentation, on différencie les méthodes private des méthodes public, du fait que les premières sont responsables de l'implémentation de la classe, alors que les secondes le sont de l'interface de la classe. Comme indiqué à la figure ci-dessous, la partie interface d'un classe doit rester réduite par rapport à son implémentation. Plus cette partie sera réduite, plus la possibilité d'un changement dans celle-ci est réduite, et moins conséquent devient le possible impact de changement dans cette classe. Gardez à l'esprit que l'interface ne reprend de toutes les méthodes de la classe, que les seules possible messages, c'est-à-dire les signatures  des méthodes publiques. Ce sont les seules signatures qui ne peuvent évoluer dans le temps, car même le corps des méthodes identifiées par ces signatures peut être modifié, sans conséquence sur les autres classes. De son côté, la partie private est un large espace maintenu de modification possibles, tout comme un  chantier en cours.

Toujours un  soucis de stabilité, cette séparation force tout programmeur d'une classe à réfléchir de façon anticipée, afin de tenir clairement détachées les méthodes qu'ils prédestinent aux autres classes de celles qui font partie de jardin secret de la classe qu'il programme. Tout changement dans une classe qui se produit dans les méthodes d'implémentation n'affectera d'aucune manière le codage de toutes les classes interagissant avec celle-là. Les méthodes private de la classe agissent dans la mesure où elles sont appelées dans les méthodes public de cette classe. Ce qui se révèle être impossible pour le private. C'est qu'elles soient appelées de l'extérieur de la classe. 
Cette séparation private/public ne se fait pour le programmeur qu'au prix d'un travail d'anticipation concernant les fonctionnalités de ses classes qu'il juge stables dans son code pour une longue durée (et qu'il peut rendre publiques et accessibles) et celles qu'il soupçonne d'être susceptible de changer (et qu'il vaut mieux garder private).
Signature d'une classe : son interface, dans le schéma d'interaction entre classes, qui est la base de la programmation OO, il est, en vérité, plus correct de parler d'interaction entre interface qu'entre classes. Seules les interfaces apparaissent comme disponibles aux autres classes.
Interaction  avec l'interface plutôt qu'avec la classe, lorsqu'une classe interagit avec une autre, il est plus correct de dire qu'elle interagit avec l'interface de cette dernière. Une bonne pratique de l'OO vous incite, par ailleurs, à rendre tout cela plus clair, par l'utilisation explicite des interfaces comme médiateur entre les classes.  
Une possibilité de rendre accessible les attributs et les méthodes déclarés private dans une classe à une autre classe se présente lorsque cette seconde classe est créée à l'intérieur de la première. Ce systèmes de classe imbriquées l'une dans l'autre n'est pas des plus simples à mettre en oeuvre, et ne devrait être exploité que très rarement, vu les autres modes, plus intuitifs.

Utilisation des paquetages, une autre possibilité encore, consiste à ne permettre qu'aux seuls enfants de la classes (ses héritiers) un accès aux attributs et méthodes protected. Si un objet hérite il a le droit d'exploiter toutes les caractéristiques dont il hérite. En C#, et en .Net, en général, il faut néanmoins faire la différence entre les concepts de namespace et d'assembly (les .dll de Microsoft). On installe les fichiers classes dans l'assembly lors de la compilation.
Plutôt qu'aux namespace, les niveaux d'accès et d'encapsulation seront plutôt relatifs à la découpe des classes et des fichiers correspondants en « assembly ». Il y a donc tout intérêt à nommer les namespace et les assembly de la même manière, afin de faciliter la compréhension et la gestion de l'ensemble des classes. 

Ces niveaux d'accessibilité intermédiaire ont le défaut d'accroître la portée d'un changement effectué dans une petite partie du code. Ils sacrifient, de ce fait, l'effort anticipatif qui consiste à jouer de cet accès avec la plus grande prévoyance aux futurs changements plus étendus, faisant suite à une modification quelconque du code. La charte du bon programmeur OO, vous encourage à n'utiliser que les deux accès, private et public, et avec une grande parcimonie quand aux accès public.
Désolidariser les modules,  de manière générale les deux niveaux extrêmes de l'encapsulation -private : fermé à tous et -public : ouvert a tous, cette pratique de l’encapsulation permet, tout à la fois, une meilleur modularisation et une plus grande stabilisation des codes, en désolidarisant autant que faire se peut les réalisations des différents modules.

Afin d'éviter l'effet papillon, la physique d'aujourd'hui s'intéresse de près à la modélisation et la compréhension de système complexe composés de multiples agents simples en interaction. Stuart Kauffman est un de ces chercheurs qui se sont appliqués à  comprendre le fonctionnement de tels réseaux, et surtout, l'impact sur ce fonctionnement de la façon dont les agents sont interconnectés. De ces nombreuses études sur des systèmes et réseaux aussi variés que les réseaux de neurones, réseaux génétiques, immunitaires, verre de spin et autres, il résulte que ces systèmes ont les comportements les plus riches quand les agents ne sont pas trop insuffisamment connectés entre eux et quand ils ne le sont pas trop. 

Aucun commentaire: