Chapitre 5. Collaboration entre classes
Le but de ce chapitre est de poursuivre la découpe d'une application OO en ses classes jouant,tout à la fois, le rôle de module, fichier et type.
Pour en finir avec la lutte des classes,la programmation OO se conçoit, essentiellement, comme une société de classes en intéraction, se déléguant mutuellement un ensemble de services. Les classes, lors de leur conception, prévoient ces services, pour que leur compilateur s'assure de la cohérence et de la qualité de cette conception, et traduire le tout en une forme exécutable. Par la suite, ces services s'exécuteront en cascade, quand les objets, instances de ces classes, occuperont la mémoire et se référenceront mutuellement, afin de réaliser le programme anticipé par la structure relationnelle des classes.
En C#, il est nécessaire, pour que la classe 01 (installée dans un fichier 01.cs) puisse se rattacher à la classe 02 (installée dans un fichier 02.cs), de faire d'abord de la classe 02 une librairie « dll » (dynamic link library, extension qui ne surprendra en rien les habitués de Windows). Ensuite faut compiler le fichier 01.cs, en faisant le lien avec le fichier dll généré précédemment.
Fichier dll, les fichiers portant l'extension .dll sont des fichiers caractéristiques des plates-formes Windows et qui permettent de relier dynamiquement plusieurs fichiers exécutables. C'est la raison pour laquelle, afin de rendre les nouveaux exécutables C# compatibles avec la plate-forme Windows, il faut en faire des .dll. Dans la plate-forme de développement .Net, ces fichier .dll permettent de faire le lien entre n'importe quelles classes développées dans n'importe lequel des langages de programmation supporté par .Net.
De l'association unidirectionnelle à l'association bidirectionnelle, une question assez légitime peut être posée, quand on s'aperçoit que la liaison dynamique à la compilation se fait, soit en ordonnant les compilations, comme en C#, a savoir d'abord en compilant le premier fichier dont dépend le second, ensuite le second. Que se passe-t-il quand les deux classes dépendent mutuellement l'une de l'autre.Exemple entre un employé et son employeur, un joueur de basket et son coach. L'association entre deux classes est bidirectionnelle quand des messages peuvent être envoyés dans les deux sens.
En C#, comme l'ordre de compilation est déterminé par les liens de dépendances entre les classes, la solution la plus immédiate parmi d'autres, consistera à compiler les fichiers, tous ensemble, et non plus de manière séparée.
Auto-association, les classes peuvent bien évidement s'adresser à elles-mêmes, en devenant les destinataires de leur propre message comme montré dans le diagramme ci-après.
Lors de l'exécution d'une de ses méthodes, un objet peut demander à une autre de ses méthodes de s'exécuter.Il s'agit du mécanisme procédural classique d'appel imbriqué de méthodes, comme indiqué dans le code suivant.
faireQuelqueChose(int a) {
...
faireAutreChose( ) ;
}
Appel imbriqué de méthodes, force est de constater que l'OO ne se départ pas vraiment du procédural. L'intérieur de toutes les méthodes est, de ce fait, programmé en mode procédural comme une succession d'instructions, assignation, boucle, condition ... L'OO vous incite principalement à penser différemment la manière de répartir le travail entre les méthodes et la façon dont les méthodes s'associent aux données qu'elles manipulent, mais ces manipulations restent entièrement de type procédural. Ces imbrications entre macrofonctions sont la base de la programmation procédurale, ici nous les retrouvons à une échelle réduite, car les fonctions auront préalablement été redistribuées entre les classes.
Plus généralement, tout objet d'une classe donnée peut contenir dans les corps d'une de ses méthodes un appel de méthode à exécuter sur un autre objet, mais toujours de la même classe, comme dans le code qui suit :
class 01{
01 unAutre01 ;
faireQuelqueChose() {
unAutre01.faireAutreChose( ) ;
}
}
un joueur de basket peu faire la passe à un autre joueur. Le prédateur peut partir à la recherche d'un autre prédateur.
Les diagrammes de séquence UML qui suivent montrent la différence entre les deux cas, différence qui se marque dans le destinataire du message.
1. Envoi de message au même objet :
2. Envoi de message à un autre objet de la même classe :
Alors qu'il s'agira, contrairement au cas précédent, d'un transfert de message entre deux objets différents, du point de vue des classes, il s'agira d'une interaction entre une classe et elle-même.
Package et namespace, au même titre que vous organisez vos fichiers dans une structure hiérarchisée de répertoires, vous organiserez vos classes dans une structure isomorphe de paquetage (namespace). Il s'agit là uniquement, d'un mécanisme de nommage de classes, comme les répertoires le sont pour les fichiers, qui vous permet, tout à la fois, de regrouper vos classes partageant une même thématique et de ce fait un même domaine sémantique, et de donner un nom identique à deux classes placées dans des packages différents.
Using en C#, vos classes étant regroupées en paquetages imbriqués, il est indispensable, lors de leur utilisation, soit de spécifier leur nom complet : « Paquetage.classe » (d'abord le nom du paquetage puis le nom de la classe), soit d'indiquer, au début du code, le paquetage qui doit être utilisé afin de retrouver les classes exploitées dans le fichier. Cela se fait par l'addition, au début des codes, de l'instruction using en C# .
Aucun commentaire:
Enregistrer un commentaire