Livret 03.2 Csharp

Livret 3.
2
Le langage C# dans .Net
--Classes, objets, hritage, polymorphisme dobjets, de mthode, dlgation.
RM di scala
Cours informatique programmation
Rm di Scala -
http://www.discala.net
SOMMAIRE
Classes, objets et mthodes et hritage Polymorphisme d'objets Polymorphisme de mthodes Polymorphisme d'interfaces Classe de dlgation 36 48 73 98
rm di Scala - 2006
Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005
page
Classes, objets et mthodes
Plan gnral:
1. Les classes C# : des nouveaux types

1.1 Dclaration d'une classe 1.2 Une classe est un type en C# 1.3 Toutes les classes ont le mme anctre - hritage 1.4 Encapsulation des classes 1.5 Exemple de classe imbrique dans une autre classe 1.6 Exemple de classe inclue dans un mme espace de noms 1.7 Mthodes abstraites 1.8 Classe abstraite, Interface
2. Les objets : des rfrences ou des valeurs

2.1 Modle de la rfrence 2.2 Les constructeurs d'objets rfrence ou valeurs 2.3 Utilisation du constructeur d'objet par dfaut 2.4 Utilisation d'un constructeur d'objet personnalis 2.5 Le mot clef this- cas de la rfrence seulement
3. Variables et mthodes
3.1 Variables dans une classe en gnral 3.2 Variables et mthodes d'instance 3.3 Variables et mthodes de classe - static 3.4 Bilan et exemple d'utilisation
page
Introduction
Nous proposons des comparaisons entre les syntaxes de C# et Delphi et/ou Java, lorsque les dfinitions sont semblables. Tableau des limitations des niveaux de visibilit fourni par microsoft :
Modification de visibilit Rappelons les classiques modificateurs de visibilit des variables et des mthodes dans les langages orients objets, dont C# dispose : Les mots clef (modularit public-priv)
par dfaut (aucun mot clef) public Les variables et les mthodes d'une classe non prcdes d'un mot clef sont private et ne sont visibles que dans la classe seulement. Les variables et les mthodes d'une classe prcdes du mot clef public sont visibles par toutes les classes de tous les modules. Les variables et les mthodes d'une classe prcdes du mot clef private ne sont visibles que dans la classe seulement. Les variables et les mthodes d'une classe prcdes du mot clef protected sont visibles par toutes les classes incluses dans le module, et par les classes drives de cette classe. Les variables et les mthodes d'une classe prcdes du
)
private
protected
rm di Scala - 2006
internal
page
mot clef internal sont visibles par toutes les classes inclues dans le mme assembly.
Les attributs d'accessibilit public, private, protected sont identiques ceux de Delphi et Java, pour les classes nous donnons ci-dessous des informations sur leur utilisation. L'attribut internal joue peu prs le rle (au niveau de l'assembly) des classes Java dclares sans mot clef dans le mme package , ou des classes Delphi dclares dans la mme unit (classes amies). Toutefois pour des raisons de scurit C# ne possde pas la notion de classe amie.
1. Les classes : des nouveaux types

Rappelons un point fondamental dj indiqu : tout programme C# contient une ou plusieurs classes prcdes ou non d'une dclaration d'utilisation dautres classes contenues dans des bibliothques (clause using) ou dans un package complet compos de nombreuses classes. La notion de module en C# est reprsente par l'espace de noms (clause namespace) semblable au package Java, en C# vous pouvez omettre de spcifier un namespace, par dfaut les classes dclares le sont automatiquement dans un espace 'sans nom' (gnralement qualifi de global) et tout identificateur de classe dclar dans cet espace global sans nom est disponible pour tre utilis dans un espace de noms nomm. Contrairement Java, en C# les classes non qualifies par un modificateur de visibilit (dclares sans rien devant) sont public. Delphi
Unit Biblio; interface // les dclarations des classes implementation // les implmentations des classes end. si pas de nom de package alors automatiquement dans : package java.lang; } si pas de nom d'espace de noms alors automatiquement dans l'espace global.
Java
package Biblio;
C#
namespace Biblio { // les dclarations et implmentation des classes
// les dclarations et implmentation des classes
1.1 Dclaration d'une classe En C#, nous n'avons pas comme en Delphi, une partie dclaration de la classe et une partie implmentation spares l'une de l'autre. La classe avec ses attributs et ses mthodes sont dclars et implments un seul endroit comme en Java. Delphi Java
)
C#
page
interface uses biblio; type Exemple = class x : real; y : integer; function F1(a,b:integer): real; procedure P2; end; implementation function F1(a,b:integer): real; begin ...........code de F1 end; procedure P2; begin ...........code de P2 end; end.
import biblio; class Exemple { float x; int y; float F1(int a, int b) { ...........code de F1 } void P2( ) { ...........code de P2 } }
using biblio; namespace Machin { class Exemple { float x; int y; float F1(int a, int b) { ...........code de F1 } void P2( ) { ...........code de P2 } } }
1.2 Une classe est un type en C# Comme en Delphi et Java, une classe C# peut tre considre comme un nouveau type dans le programme et donc des variables d'objets peuvent tre dclares selon ce nouveau "type". Une dclaration de programme comprenant 3 classes : Delphi
interface type Un = class ... end; Deux = class ... end; Appli3Classes = class x : Un; y : Deux; public procedure main; end; implementation procedure Appli3Classes.main; var x : Un; y : Deux; begin ... end; end.
Java
class Appli3Classes { Un x; Deux y; public static void main(String [ ] arg) { Un x; Deux y; ... } } class Un { ... } class Deux { ... }
C#
class Appli3Classes { Un x; Deux y; static void Main(String [ ] arg) { Un x; Deux y; ... } } class Un { ... } class Deux { ... }
rm di Scala - 2006
page
1.3 Toutes les classes ont le mme anctre - hritage Comme en Delphi et en Java, toutes les classes C# drivent automatiquement d'une seule et mme classe anctre : la classe Object. En C# le mot-clef pour indiquer la drivation (hritage) partir d'une autre classe est le symbole deux points ':', lorsqu'il est omis c'est donc que la classe hrite automatiquement de la classe Object : Les deux dclarations de classe ci-dessous sont quivalentes : Delphi
type Exemple = class ( TObject ) ...... end; type Exemple = class ...... end;
Java
class Exemple extends Object { ....... } class Exemple { ....... }
C#
class Exemple : Object { ....... } class Exemple { ....... }
L'hritage en C# est tout fait classiquement de l'hritage simple comme en Delphi et en Java. Une classe fille qui drive d'une seule classe mre, hrite de sa classe mre toutes ses mthodes et tous ses champs. En C# la syntaxe de l'hritage fait intervenir le symbole clef ':', comme dans "class Exemple : Object". Une dclaration du type : class ClasseFille : ClasseMere { } signifie que la classe ClasseFille dispose de tous les attributs et de toutes les mthodes de la classe ClasseMere. Comparaison hritage : Delphi
type ClasseMere = class // champs de ClasseMere // mthodes de ClasseMere end; ClasseFille = class ( ClasseMere )
// hrite des champs de ClasseMere // hrite des mthodes de ClasseMere
Java
class ClasseMere { // champs de ClasseMere // mthodes de ClasseMere } class ClasseFille extends ClasseMere {
C#
class ClasseMere { // champs de ClasseMere // mthodes de ClasseMere } class ClasseFille : ClasseMere {
end;
Bien entendu une classe fille peut dfinir de nouveaux champs et de nouvelles mthodes qui lui sont propres.
1.4 Encapsulation des classes

)
page
La visibilit et la protection des classes en Delphi est apporte par le module Unit o toutes les classes sont visibles dans le module en entier et ds que la unit est utilise les classes sont visibles partout. Il n'y a pas de possibilit d'imbriquer une classe dans une autre. En C#, nous avons la possibilit d'imbriquer des classes dans d'autres classes (classes internes), par consquent la visibilit de bloc s'applique aussi aux classes. Remarque La notion de classe interne de C# (qui n'existe pas en Delphi) est sensiblement dioffrente de celle de Java (pas de classe locale et pas de classe anonyme mais des mthodes anonymes), elle corespond la notion de classe membre de Java.
Mots clefs pour la protection des classes et leur visibilit : Une classe C# peut se voir attribuer un modificateur de comportement sous la forme d'un mot clef devant la dclaration de classe. Par dfaut si aucun mot clef n'est indiqu la classe est visible dans tout le namespace dans lequel elle est dfinie. Il y a 4 qualificateurs possibles pour modifier le comportement de visibilit d'une classe selon sa position (imbrique ou non) : public, private, protected, internal (dnomms modificateurs d'accs) et abstract (qualificateur d'abstraction pouvant tre associ l'un des 3 autres modificateurs d'accs). On rappelle que sans qualificateur public, private, internal ou protected, une classe C# est automatiquement public. Le nom du fichier source dans lequel plusieurs classes C# sont stockes n'a aucun rapport avec le nom d'une des classes dclares dans le texte source, il est laiss au libre choix du dveloppeur et peut ventuellement tre celui d'une classe du namespace etc...
Tableau des possibilits fourni par microsoft :
Attention
rm di Scala - 2006
Par dfaut dans une classe tous les membres sans qualificateur de visibilit (classes internes inclues) sont private.
)
page
C# mot clef abstract : abstract class ApplicationClasse1 { ... } mot clef public : public class ApplicationClasse2 { ... } mot clef protected : protected class ApplicationClasse3 { ... } mot clef internal : internal class ApplicationClasse4 { ... } mot clef private : private class ApplicationClasse5 { ... } pas de mot clef : class ApplicationClasse6 { ... } - sauf si c'est une classe interne
Explication classe abstraite non instanciable. Aucun objet ne peut tre cr. classe visible par n'importe quel programme d'un autre namespace classe visible seulement par toutes les autres classes hritant de la classe conteneur de cette classe.
classe visible seulement par toutes les autres classes du mme assembly. classe visible seulement par toutes les autres classes du mme namespace o elle est dfinie.
qualifie public -si c'est une classe interne elle est alors qualifie private.
Nous remarquons donc qu'une classe ds qu'elle est dclare dans lespace de noms est toujours visible et par dfaut public, que le mot clef public soit prsent ou non. Les mots clefs abstract et protected n'ont de l'influence que pour l'hritage. Remarque La notion de classe sealed en C# correspond strictement la notion de classe final de Java : ce sont des classes non hritables.
Nous tudions ci-aprs la visibilit des classes prcdentes dans deux contextes diffrents.
1.5 Exemple de classes imbriques dans une autre classe Dans le premier contexte, ces six classes sont utilises en tant intgres (imbriques) une classe publique. La classe ApplicationClasses : C# Explication
page
namespace Exemple { public class ApplicationClasses { abstract class ApplicationClasse1 { ... } public class ApplicationClasse2 { ... } protected class ApplicationClasse3 { ... } internal class ApplicationClasse4 { ... } private class ApplicationClasse5 { ... } class ApplicationClasse6 { ... } } }
Ces 6 "sous-classes" sont visibles ou non, partir de l'accs la classe englobante "ApplicationClasses", elles peuvent donc tre utilises dans tout programme qui utilise la classe "ApplicationClasses".
Par dfaut la classe ApplicationClasse6 est ici private.
Un programme utilisant la classe ApplicationClasses : C# Explication
Le programme de gauche "class AppliTestClasses" utilise la classe prcdente ApplicationClasses et ses sous-classes. La notation uniforme de chemin de classe est standard.
namespace Exemple { class AppliTestClasses { ApplicationClasses.ApplicationClasse2 a2; } }
Seule la classe interne ApplicationClasse2 est visible et permet d'instancier un objet.
1.6 Mme exemple de classes non imbriques situes dans le mme espace de noms
rm di Scala - 2006
Dans ce second exemple, ces mmes 6 classes sont utilises en tant incluses dans le mme namespace.
)
page
C#
Explication
Une classe dans un espace de nom ne peut pas tre qualifie protected ou private (si elle est imbrique comme ci-haut cela est possible): Les classes ApplicationClasse3 et ApplicationClasse5 ne peuvent donc pas faire partie du mme namespace Exemple. La classe ApplicationClasse1 est ici abstraite et public, donc visible. La classe ApplicationClasse2 est public, donc visible. La classe ApplicationClasse4 n'est visible que dans le mme assembly. Par dfaut la classe ApplicationClasse6 est ici public, donc visible.
namespace Exemple { abstract class ApplicationClasse1 { ... } public class ApplicationClasse2 { ... } protected class ApplicationClasse3 { ... } internal class ApplicationClasse4 { ... } private class ApplicationClasse5 { ... } class ApplicationClasse6 { ... } }
Un programme AppliTestClasses utilisant ces 4 classes : C# dans deux namespace diffrents Explication
Le programme de gauche "class AppliTestClasses" utilise les classes qui composent le namespace Exemple.
Cette classe AppliTestClasses est dfinie dans un autre namespace dnomm Essai qui est suppos ne pas faire partie du mme assembly que le namespace Exemple. Elle ne voit donc pas la classe ApplicationClasse4 (visible dans le mme assembly seulement).
using Exemple; namespace Essai { class AppliTestClasses{ ApplicationClasse2 a2; ApplicationClasse6 a6; } }
Si l'on veut instancier des objets, seules les classes ApplicationClasse2 et ApplicationClasse6 sont de bonnes candidates, car la classe ApplicationClasse1 bien qu'elle soit visible est abstraite.
page
10
C# dans le mme namespace
Explication
Le programme de gauche "class AppliTestClasses" utilise les classes qui composent le namespace Exemple.
La classe AppliTestClasses est dfinie dans le mme namespace Exemple que les 4 autres classes. Toutes les classes du mme namespace sont visibles entre elles. namespace Exemple { class AppliTestClasses{ ApplicationClasse1 a1; ApplicationClasse2 a2; ApplicationClasse4 a4; ApplicationClasse6 a6; } } Ici les toutes les 4 classes sont visibles pour la classe AppliTestClasses.
Remarque pratique : Selon sa situation imbrique ou non imbrique, une classe peut ou ne peut pas tre qualifie par les divers modificateurs de visibilit. En cas de doute le compilateur fournit un diagnostique clair, comme ci-dessous : [C# Erreur] Class.cs(nn): Les lments namespace ne peuvent pas tre dclars explicitement comme private, protected ou protected internal.
1.7 Mthodes abstraites Le mot clef abstract est utilis pour reprsenter une classe ou une mthode abstraite. Quel est l'intrt de cette notion ? Avoir des modles gnriques permettant de dfinir ultrieurement des actions spcifiques.
Une mthode dclare en abstract dans une classe mre :

rm di Scala - 2006
N'a pas de corps de mthode. N'est pas excutable.

)
page
11
Doit obligatoirement tre redfinie dans une classe fille.
Une mthode abstraite n'est qu'une signature de mthode sans implmentation dans la classe. Exemple de mthode abstraite : class Etre_Vivant { } La classe Etre_Vivant est une classe mre gnrale pour les tres vivants sur la plante, chaque catgorie d'tre vivant peut tre reprsente par une classe drive (classe fille de cette classe) : class Serpent : Etre_Vivant { } class Oiseau : Etre_Vivant { } class Homme : Etre_Vivant { } Tous ces tres se dplacent d'une manire gnrale, donc une mthode SeDeplacer est commune toutes les classes drives, toutefois chaque espce excute cette action d'une manire diffrente et donc on ne peut pas dire que se dplacer est une notion concrte mais une notion abstraite que chaque sous-classe prcisera concrtement. En C#, les mthodes abstraites sont automatiquement virtuelles, elles ne peuvent tre dclares que public ou protected, enfin elles doivent tre redfinies avec le qualificateur override. Cidessous deux dclarations possibles pour le dplacement des tres vivants :
abstract class Etre_Vivant { public abstract void SeDeplacer( ); } class Serpent : Etre_Vivant { public override void SeDeplacer( ) { //.....en rampant } } class Oiseau : Etre_Vivant { public override void SeDeplacer( ) { //.....en volant } } class Homme : Etre_Vivant { public override void SeDeplacer( ) { //.....en marchant } }
abstract class Etre_Vivant { protected abstract void SeDeplacer( ); } class Serpent : Etre_Vivant { protected override void SeDeplacer( ) { //.....en rampant } } class Oiseau : Etre_Vivant { protected override void SeDeplacer( ) { //.....en volant } } class Homme : Etre_Vivant { protected override void SeDeplacer( ) { //.....en marchant } }
Comparaison de dclaration d'abstraction de mthode en Delphi et C# : Delphi

type Etre_Vivant = class
C#
abstract class Etre_Vivant { public abstract void SeDeplacer( );
)
page
12
procedure SeDeplacer;virtual; abstract ; end; Serpent = class ( Etre_Vivant ) procedure SeDeplacer; override; end; Oiseau = class ( Etre_Vivant ) procedure SeDeplacer; override; end; Homme = class ( Etre_Vivant ) procedure SeDeplacer; override; end;
} class Serpent : Etre_Vivant { public override void SeDeplacer( ) { //.....en rampant } } class Oiseau : Etre_Vivant { public override void SeDeplacer( ) { //.....en volant } } class Homme : Etre_Vivant { public override void SeDeplacer( ) { //.....en marchant } }
En C# une mthode abstraite est une mthode virtuelle nayant pas dimplmentation dans la classe o elle est dclare. Son implmentation est dlgue une classe drive. Les mthodes abstraites doivent tre dclares en spcifiant la directive abstract .
1.8 Classe abstraite, Interface Classe abstraite Comme nous venons de le voir dans l'exemple prcdent, une classe C# peut tre prcde du mot clef abstract, ce qui signifie alors que cette classe est abstraite, nous avons les contraintes de dfinition suivantes pour une classe abstraite en C# : Si une classe contient au moins une mthode abstract, elle doit imprativement tre dclare en classe abstract elle-mme. C'est ce que nous avons crit au paragraphe prcdent pour la classe Etre_Vivant que nous avons dclare abstract parce qu'elle contenait la mthode abstraite SeDeplacer. Une classe abstract ne peut pas tre instancie directement, seule une classe drive (sous-classe) qui redfinit obligatoirement toutes les mthodes abstract de la classe mre peut tre instancie. Consquence du paragraphe prcdent, une classe drive qui redfinit toutes les mthodes abstract de la classe mre sauf une (ou plus d'une) ne peut pas tre instancie et subit la mme rgle que la classe mre : elle contient au moins une mthode abstraite donc elle est aussi une classe abstraite et doit donc tre dclare en abstract. Une classe abstract peut contenir des mthodes non abstraites et donc implantes dans la classe. Une classe abstract peut mme ne pas contenir du tout de mthodes abstraites, dans ce cas une classe fille n'a pas la ncessit de redfinir les mthodes de la classe mre pour tre instancie. Delphi contrairement C# et Java, ne possde pas ce jour le modle de la classe abstraite, seule la version Delphi2005 pour le Net Framework possde les mmes caractristiques que C#. Interface Lorsqu'une classe est dclare en abstract et que toutes ses mthodes sont dclares en abstract, on appelle en C# une telle classe une Interface.
rm di Scala - 2006
page
13
Rappel classes abstraites-interfaces
Les interfaces ressemblent aux classes abstraites sur un seul point : elles contiennent des membres expliquant certains comportements sans les implmenter. Les classes abstraites et les interfaces se diffrencient principalement par le fait qu'une classe peut implmenter un nombre quelconque d'interfaces, alors qu'une classe abstraite ne peut hriter que d'une seule classe abstraite ou non.
Vocabulaire et concepts :

Une interface est un contrat, elle peut contenir des proprits, des mthodes et des vnements mais ne doit contenir aucun champ ou attribut. Une interface ne peut pas contenir des mthodes dj implmentes. Une interface doit contenir des mthodes non implmentes. Une interface est hritable. On peut contsruire une hirarchie d'interfaces. Pour pouvoir construire un objet partir d'une interface, il faut dfinir une classe non abstraite implmentant toutes les mthodes de l'interface.
Une classe peut implmenter plusieurs interfaces. Dans ce cas nous avons une excellente alternative l'hritage multiple. Lorsque l'on cre une interface, on fournit un ensemble de dfinitions et de comportements qui ne devraient plus tre modifis. Cette attitude de constance dans les dfinitions, protge les applications crites pour utiliser cette interface. Les variables de types interface respectent les mmes rgles de transtypage que les variables de types classe. Les objets de type classe clA peuvent tre transtyps et refrencs par des variables d'interface IntfA dans la mesure o la classe clA implmente linterface IntfA. (cf. polymorphisme d'objet)
Si vous voulez utiliser la notion d'interface pour fournir un polymorphisme une famille de classes, elles doivent toutes implmenter cette interface, comme dans l'exemple ci-dessous. Exemple : l'interface Vhicule dfinissant 3 mthodes (abstraites) Demarrer, RpartirPassagers de
)
page
14
rpartition des passagers bord du vhicule (fonction de la forme, du nombre de places, du personnel charg de s'occuper de faire fonctionner le vhicule...), et PriodicitMaintenance renvoyant la priodicit de la maintenance obligatoire du vhicule (fonction du nombre de km ou miles parcourus, du nombre d'heures d'activits,...) Soit l'interface Vhicule dfinissant ces 3 mthodes : interface IVehicule{ void Demarrer( ); void RpartirPassager( ); void PriodicitMaintenance( ); } Soient les deux classes Vhicule terrestre et Vhicule marin, qui implmentent partiellement chacune l'interface Vhicule , ainsi que trois classes voiture, voilier et croiseur hritant de ces deux classes :
Les trois mthodes de l'interface Vhicule sont abstraites et publiques par dfinition. Les classes Vhicule terrestre et Vhicule marin sont abstraites, car la mthode abstraite Demarrer de l'interface Vhicule n'est pas implmente elle reste comme "modle" aux futures classes. C'est dans les classes voiture, voilier et croiseur que l'on implmente le comportement prcis du genre de dmarrage.
Dans cette vision de la hirarchie on a suppos que les classes abstraites Vhicule terrestre et Vhicule marin savent comment rpartir leur ventuels passagers et quand effectuer une maintenance du vhicule. Les classes voiture, voilier et croiseur , n'ont plus qu' implmenter chacune son propre comportement de dmarrage.
rm di Scala - 2006
Une interface C# peut tre qualifie par un des 4 modificateur public, protected, internal, private.
)
page
15
Contrairement Java, une classe abstraite C# qui implmente une interface doit obligatoirement dclarer toutes les mthodes de l'interface, celles qui ne sont pas implmentes dans la classe abstraite doivent tre dclares abstract. C'est le cas dans l'exemple ci-dessous pour la mthode abstraite Demarrer , nous proposons deux critures possibles pour cette hirarchie de classe : C# mthode abstraite sans corps
interface IVehicule{ void Demarrer( ); void RpartirPassager( ); void PriodicitMaintenance( ); } abstract class Terrestre : IVehicule { public abstract void Demarrer( ); public void virtual RpartirPassager( ){...} public void virtual PriodicitMaintenance( ){...} } class Voiture : Terrestre { override public void Demarrer( ){...} } abstract class Marin : IVehicule { public abstract void Demarrer( ); public void virtual RpartirPassager( ){...} public void virtual PriodicitMaintenance( ){...} } class Voilier : Marin { override public void Demarrer( ){...} } class Croiseur : Marin { override public void Demarrer( ){...} }
C# mthode virtuelle corps vide

interface IVehicule{ void Demarrer( ); void RpartirPassager( ); void PriodicitMaintenance( ); } abstract class Terrestre : IVehicule { public virtual void Demarrer( ){} public void virtual RpartirPassager( ){...} public void virtual PriodicitMaintenance( ){...} } class Voiture : Terrestre { override public void Demarrer( ){...} } abstract class Marin : IVehicule { public virtual void Demarrer( ) {} public void virtual RpartirPassager( ){...} public void virtual PriodicitMaintenance( ){...} } class Voilier : Marin { override public void Demarrer( ){...} } class Croiseur : Marin { override public void Demarrer( ){...} }
Les mthodes RpartirPassagers, PriodicitMaintenance et Demarrer sont implantes en virtual , soit comme des mthodes liaison dynamique, afin de laisser la possibilit pour des classes enfants de redfinir ces mthodes. Remarque : Attention le qualificateur new ne peut masquer que des membres non abstract. Un membre abstract doit imprativement tre redfini (implment) par le qualificateur override, car ce genre de membre est implicitement virtual en C#.
page
16
Soit titre de comparaison, les deux mmes critures en Java de ces classes :
Java , mthode abstraite sans corps
Java mthode virtuelle corps vide
rm di Scala - 2006
page
17
2. Les objets : des rfrences ou des valeurs

Les classes sont des descripteurs d'objets, les objets sont les agents effectifs et "vivants" implantant les actions d'un programme. Les objets dans un programme ont une vie propre : Ils naissent (ils sont crs ou allous). Ils agissent (ils s'envoient des messages grce leurs mthodes). Ils meurent (ils sont dsallous, automatiquement en C#).
C'est dans le segment de mmoire du CLR de .NetFramework que s'effectue l'allocation et la dsallocation d'objets. Objets type valeur Les classes encapsulant les types lmentaires dans .NET Framework sont des classes de type valeur du genre structures. Dans le CLS une classe de type valeur est telle que les allocations d'objets de cette classe se font directement dans la pile et non dans le tas, il n'y a donc pas de rfrence pour un objet de type valeur et lorsqu'un objet de type valeur est pass comme paramtre il est pass par valeur. Dans .NET Framework les classes-structures de type valeur sont dclares comme structures et ne sont pas drivables Objets type rfrence Le principe d'allocation et de reprsentation des objets type rfrence en C# est identique celui de Delphi il s'agit de la rfrence, qui est une encapsulation de la notion de pointeur. Dans .NET Framework les classes de type rfrence sont dclares comme des classes classiques et sont drivables. Afin d'clairer le lecteur prenons par exemple un objet x instanci partir d'une classe de type rfrence et un objet y instanci partir d'un classe de type valeur contenant les mmes membres que la classe par rfrence. Ci-dessous le schma d'allocation de chacun des deux catgories d'objets :
Pour les types valeurs, la gestion mmoire des objets est classiquement celle de la pile dynamique, un tel objet se comporte comme une variable locale de la mthode dans laquelle il est instanci et ne ncessite pas de gestion supplmentaire. Seuls les objets type rfrence instancis sur le tas, ncessitent une gestion mmoire spciale que nous dtaillons ci-aprs (dans un
)
page
18
programme C# les types rfrences du dveloppeur reprsentent prs de 99% des objets du programme). 2.1 Modle de la rfrence en C# Rappelons que dans le modle de la rfrence chaque objet (reprsent par un identificateur de variable) est caractris par un couple (rfrence, bloc de donnes). Comme en Delphi, C# dcompose l'instanciation (allocation) d'un objet en deux tapes : La dclaration d'identificateur de variable type qui contiendra la rfrence, la cration de la structure de donnes elle-mme (bloc objet de donnes) avec new.
Delphi type Un = class ...... end; // la dclaration : var x , y : Un; .... // la cration : x := Un.create ; y := Un.create ; class Un { ... } // la dclaration : Un x , y ; .... // la cration : x = new Un( ); y = new Un( );
C#
Aprs excution du pseudo-programme prcdent, les variables x et y contiennent chacune une rfrence (adresse mmoire) vers un bloc objet diffrent:
Un programme C# est fait pour tre excut par l'environnement CLR de .NetFramework. Deux objets C# seront instancis dans le CLR de la manire suivante :
rm di Scala - 2006
page
19
Attitude rapprocher pour comparaison, celle dont Delphi gre les objets dans une pile d'excution de type LIFO et un tas :
Attention l'utilisation de l'affectation entre variables d'objets dans le modle de reprsentation par rfrence. L'affectation x = y ne recopie pas le bloc objet de donnes de y dans celui de x, mais seulement la rfrence (l'adresse) de y dans la rfrence de x. Visualisons cette remarque importante : Situation au dpart, avant affectation
Situation aprs l'affectation " x = y "
En C#, la dsallocation tant automatique, le bloc de donnes objet qui tait rfrenc par y avant
)
page
20
l'affectation, n'est pas perdu, car le garbage collector se charge de restituer la mmoire libre au segment de mmoire du CLR
2.2 Les constructeurs d'objets rfrences ou valeurs Un constructeur est une mthode spciale d'une classe dont la seule fonction est d'instancier un objet (crer le bloc de donnes). Comme en Delphi une classe C# peut possder plusieurs constructeurs, il est possible de pratiquer des initialisations d'attributs dans un constructeur. Comme toutes les mthodes, un constructeur peut avoir ou ne pas avoir de paramtres formels. Si vous ne dclarez pas de constructeur spcifique pour une classe, par dfaut C# attribue automatiquement un constructeur sans paramtres formels, portant le mme nom que la classe. A la diffrence de Delphi o le nom du constructeur est quelconque, en C# le( ou les) constructeur doit obligatoirement porter le mme nom que la classe (majuscules et minuscules comprises). Un constructeur d'objet d'une classe n'a d'intrt que s'il est visible par tous les programmes qui veulent instancier des objets de cette classe, c'est pourquoi l'on mettra toujours le mot clef public devant la dclaration du constructeur. Un constructeur est une mthode spciale dont la fonction est de crer des objets, dans son en-tte il n'a pas de type de retour et le mot clef void n'est pas non plus utilis !
Soit une classe dnomme Un dans laquelle, comme nous l'avons fait jusqu' prsent nous n'indiquons aucun constructeur spcifique : class Un { int a; } Automatiquement C# attribue un constructeur public cette classe public Un ( ). C'est comme si C# avait introduit dans votre classe votre insu , une nouvelle mthode dnomme Un. Cette mthode "cache" n'a aucun paramtre et aucune instruction dans son corps. Ci-dessous un exemple de programme C# correct illustrant ce qui se passe : class Un { public Un ( ) { } int a; }
Vous pouvez programmer et personnaliser vos propres constructeurs. Une classe C# peut contenir plusieurs constructeurs dont les en-ttes diffrent uniquement par la liste des paramtres formels.
rm di Scala - 2006
page
21
Exemple de constructeur avec instructions : C# class Un { public Un ( ) { a = 100 } int a; } Explication
Le constructeur public Un sert ici initialiser 100 la valeur de l'attribut "int a" de chaque objet qui sera instanci.
Exemple de constructeur avec paramtre : C# class Un { public Un (int b ) { a = b; } int a; } Explication Le constructeur public Un sert ici initialiser la valeur de l'attribut "int a" de chaque objet qui sera instanci. Le paramtre int b contient cette valeur.
Exemple avec plusieurs constructeurs : C# class Un { public Un (int b ) { a = b; } public Un ( ) { a = 100; } public Un (float b ) { a = (int)b; } int a; } Explication
La classe Un possde 3 constructeurs servant initialiser chacun d'une manire diffrente le seul attribut int a.
Il est possible de rappeller un constructeur de la classe dans un autre constructeur, pour cela C# utilise comme Java le mot clef this, avec une syntaxe diffrente : Exemple avec un appel un constructeur de la mme classe: C# class Un { int a; public Un (int b ) { a = b; } public Un ( ) Explication La classe Un possde 3 constructeurs servant initialiser chacun d'une manire diffrente le seul attribut int a.
Soit le dernier constructeur : public Un (int x , float y ) : this(y)

)
page
22
{ a = 100; } public Un (float b ) { a = (int)b; } public Un (int x , float y ) : this(y) { a += 100; } }
{ a += 100; } Ce constructeur appelle tout d'abord le constructeur Un (float y ) par l'intermdiaire de this(y), puis il excute le corps de mthode soit : a += 100; Ce qui revient calculer : a = (int)y + 100 ;
Comparaison Delphi - C# pour la dclaration de constructeurs Delphi Un = class a : integer; public constructor creer; overload; constructor creer (b:integer); overload; constructor creer (b:real); overload; end; implementation constructor Un.creer; begin a := 100 end; constructor Un.creer(b:integer); begin a := b end; constructor Un.creer(b:real); begin a := trunc(b) end; constructor Un.creer(x:integer; y:real); begin self.creer(y); a := a+100; end; class Un { int a; public Un ( ) { a = 100; } public Un (int b ) { a = b; } public Un (float b ) { a = (int)b; } public Un (int x , float y ) : this(y) { a += 100; } } C#
En Delphi un constructeur a un nom quelconque, tous les constructeurs peuvent avoir des noms diffrents ou le mme nom comme en C#.
2.3 Utilisation du constructeur d'objet automatique (par dfaut) Le constructeur d'objet par dfaut de toute classe C# qu'elle soit de type valeur ou de type rfrence, comme nous l'avons signal plus haut est une mthode spciale sans paramtre, l'appel cette mthode spciale afin de construire un nouvel objet rpond une syntaxe spcifique par
)
rm di Scala - 2006
page
23
utilisation du mot clef new. Syntaxe Pour un constructeur sans paramtres formels, l'instruction d'instanciation d'un nouvel objet partir d'un identificateur de variable dclare selon un type de classe, s'crit syntaxiquement ainsi :
Exemple : (deux faons quivalentes de crer un objet x de classe Un) Un x ; x = new Un( );
Un x = new Un( )
Cette instruction cre dans le segment de mmoire, un nouvel objet de classe Un dont la rfrence (l'adresse) est mise dans la variable x, si x est de type rfrence, ou bien l'objet est directement cr dans la pile et mis dans la variable x, si x est de type valeur.
Soit Un une classe de type rfrence et Deux une autre classe de type valeur, ci-dessous une image des rsulats de l'instanciation d'un objet de chacune de ces deux classes : Un x = new Un( ) ; Deux y = new Deux ( ) ;
Dans l'exemple ci-dessous, nous utilisons le constructeur par dfaut de la classe Un , pour crer deux objets dans une autre classe : class Un { ... } class UnAutre {
)
page
24
// la dclaration : Un x , y ; .... // la cration : x = new Un( ); y = new Un( ); } Un programme de 2 classes, illustrant l'affectation de rfrences : C#
class AppliClassesReferences { public static void Main(String [ ] arg) { Un x,y ; x = new Un( ); y = new Un( ); System.Console.WriteLine("x.a="+x.a); System.Console.WriteLine"y.a="+y.a); y = x; x.a =12; System.Console.WriteLine("x.a="+x.a); System.Console.WriteLine("y.a="+y.a); } } class Un { int a=10; }
Explication
Ce programme C# contient deux classes : class AppliClassesReferences et class Un La classe AppliClassesReferences est une classe excutable car elle contient la mthode main. C'est donc cette mthode qui agira ds l'excution du programme.
Dtaillons les instructions

Un x,y ; x = new Un( ); y = new Un( ); System.Console.WriteLine("x.a="+x.a); System.Console.WriteLine("y.a="+y.a);
Que se passe-t-il l'excution ?

Instanciation de 2 objets diffrents x et y de type Un. Affichage de : x.a = 10 y.a = 10 La rfrence de y est remplace par celle de x dans la variable y (y pointe donc vers le mme bloc que x). On change la valeur de l'attribut a de x, et l'on demande d'afficher les attributs de x et de y : x.a = 12 y.a = 12 Comme y pointe vers x, y et x sont maintenant le mme objet sous deux noms diffrents !
y = x;
x.a =12; System.Console.WriteLine("x.a="+x.a); System.Console.WriteLine("y.a="+y.a);
2.4 Utilisation d'un constructeur d'objet personnalis L'utilisation d'un constructeur personnalis d'une classe est semblable celle du constructeur par dfaut de la classe. La seule diffrence se trouve lors de l'instanciation : il faut fournir des paramtres effectifs lors de l'appel au constructeur.
)
rm di Scala - 2006
page
25
Syntaxe
Exemple avec plusieurs constructeurs : une classe C# class Un { int a ; public Un (int b ) { a=b; } public Un ( ) { a = 100 ; } public Un (float b ) { a = (int)b ; } public Un (int x , float y ) : this(y) { a += 100; } } Des objets crs Un obj1 = newUn( ); Un obj2 = new Un( 15 ); int k = 14; Un obj3 = new Un( k ); Un obj4 = new Un( 3.25f ); float r = -5.6; Un obj5 = new Un( r ); int x = 20; float y = -0.02; Un obj6 = new Un( x , y );
2.5 Le mot clef this - cas de la rfrence seulement Il est possible de dnommer dans les instructions d'une mthode de classe, un futur objet qui sera instanci plus tard. Le paramtre ou (mot clef) this est implicitement prsent dans chaque objet instanci et il contient la rfrence l'objet actuel. Il joue exactement le mme rle que le mot clef self en Delphi. Nous avons dj vu une de ses utilisations dans le cas des constructeurs. C# class Un { public Un ( ) { a = 100; } int a; } C# quivalent class Un { public Un ( ) { this.a = 100; } int a; }
Dans le programme de droite le mot clef this fait rfrence l'objet lui-mme, ce qui dans ce cas est superflu puisque la variable int a est un champ de l'objet. Montrons deux exemples d'utilisation pratique de this.
Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005 page
26
Cas o l'objet est pass comme un paramtre dans une de ses mthodes : C#
class Un { public Un ( ) { a = 100; } public void methode1(Un x) { System.Console.WriteLine("champ a = " + x.a); } public void methode2( int b ) { a += b; methode1(this); } int a; }
Explications
La methode1(Un x) reoit un objet de type Exemple en paramtre et imprime son champ int a. La methode2( int b ) reoit un entier int b qu'elle additionne au champ int a de l'objet, puis elle appelle la mthode1 avec comme paramtre l'objet lui-mme.
Comparaison Delphi - C# sur cet exemple (similitude complte) Delphi

Un = class a : integer; public constructor creer; procedure methode1( x:Un ); procedure methode2 ( b:integer ); end; implementation constructor Un.creer; begin a := 100 end; procedure Un.methode1( x:Un ); begin showmessage( 'champ a ='+inttostr(x.a) ) end; procedure Un.methode2 ( b:integer ); begin a := a+b; methode1(self) end;
C#
class Un { public Un ( ) { a = 100; } public void methode1(Un x) { System.Console.WriteLine("champ a ="+x.a); } public void methode2( int b ) { a += b; methode1(this); } int a; }
Cas o le this sert outrepasser le masquage de visibilit : C#

class Un { int a; public void methode1(float a) { a = this.a + 7 ; } }
Explications
La methode1(float a) possde un paramtre float a dont le nom masque le nom du champ int a. Si nous voulons malgr tout accder au champ de l'objet, l'objet tant rfrenc par this, "this.a" est donc le champ int a de l'objet lui-mme.
rm di Scala - 2006
Comparaison Delphi - C# sur ce second exemple (similitude complte aussi)

)
page
27
Delphi Un = class a : integer; public procedure methode( a:real ); end; implementation procedure Un.methode( a:real );begin a = self.a + 7 ; end;
C# class Un { int a; public void methode(float a) { a = this.a + 7 ; } }
3. Variables et mthodes
Nous examinons dans ce paragraphe comment C# utilise les variables et les mthodes l'intrieur d'une classe. Il est possible de modifier des variables et des mthodes d'une classe ceci sera examin plus loin. En C#, les champs et les mthodes sont classs en deux catgories : Variables et mthodes de classe Variables et mthodes d'instance
3.1 Variables dans une classe en gnral Rappelons qu'en C#, nous pouvons dclarer dans un bloc (for, try,...) de nouvelles variables la condition qu'elles n'existent pas dj dans le corps de la mthode o elles sont dclares. Nous les dnommerons : variables locales de mthode. Exemple de variables locales de mthode : class Exemple { void calcul ( int x, int y ) {int a = 100; for ( int i = 1; i<10; i++ ) {char carlu;
System.Console.Write("Entrez un caractre : "); carlu = (char)System.Console.Read( );
La dfinition int a = 100; est locale la mthode en gnral La dfinition int i = 1; est locale la boucle for.
int b =15; a =.... ..... } }
Les dfinitions char carlu et int b sont locales au corps de la boucle for.
page
28
C# ne connat pas la notion de variable globale au sens habituel donn cette dnomination, dans la mesure o toute variable ne peut tre dfinie qu' l'intrieur d'une classe, ou d'une mthode inclue dans une classe. Donc part les variables locales de mthode dfinies dans une mthode, C# reconnat une autre catgorie de variables, les variables dfinies dans une classe mais pas l'intrieur d'une mthode spcifique. Nous les dnommerons : attributs de classes parce que ces variables peuvent tre de deux catgories. Exemple de attributs de classe : class AppliVariableClasse { float r ; void calcul ( int x, int y ) { .... } int x =100; int valeur ( char x ) { ..... } long y; } Les attributs de classe peuvent tre soit de la catgorie des variables de classe, soit de la catgorie des variables d'instance. 3.2 Variables et mthodes d'instance C# se comporte comme un langage orient objet classique vis vis de ses variables et de ses mthodes. A chaque instanciation d'un nouvel objet d'une classe donne, la machine CLR enregistre le p-code des mthodes de la classe dans la zone de stockage des mthodes, elle alloue dans le segment de mmoire autant d'emplacements mmoire pour les variables que d'objet crs. C# dnomme cette catgorie les variables et les mthodes d'instance. une classe C# class AppliInstance { int x ; int y ; } Instanciation de 3 objets AppliInstance obj1 = new AppliInstance( ); AppliInstance obj2 = new AppliInstance( ); AppliInstance obj3 = new AppliInstance( ); Les variables float r , long y et int x sont des attributs de classe (ici en fait plus prcisment, des variables d'instance). La position de la dclaration de ces variables n'a aucune importance. Elles sont visibles dans tout le bloc classe (c'est dire visibles par toutes les mthodes de la classe).
Conseil : regroupez les variables de classe au dbut de la classe afin de mieux les grer.
Segment de mmoire associ ces 3 objets si la classe AppliInstance est de type rfrence :
rm di Scala - 2006
page
29
Segment de mmoire associ ces 3 objets si la classe AppliInstance tait de type valeur (pour mmoire):
struct AppliIn stance { int x ; int y ; }
Un programme C# 2 classes illustrant l'exemple prcdent (classe rfrence): Programme C# excutable class AppliInstance { public int x = -58 ; public int y = 20 ; } class Utilise { public static void Main( ) { AppliInstance obj1 = new AppliInstance( );
)
page
30
AppliInstance obj2 = new AppliInstance( ); AppliInstance obj3 = new AppliInstance( ); System.Console.WriteLine( "obj1.x = " + obj1.x ); } }
3.3 Variables et mthodes de classe - static Variable de classe On identifie une variable ou une mthode de classe en prcdant sa dclaration du mot clef static. Nous avons dj pris la majorit de nos exemples simples avec de tels composants. Voici deux dclarations de variables de classe : static int x ; static int a = 5; Une variable de classe est accessible comme une variable d'instance(selon sa visibilit), mais aussi sans avoir instancier un objet de la classe, uniquement en rfrenant la variable par le nom de la classe dans la notation de chemin uniforme d'objet. une classe C# class AppliInstance { static int x ; int y ; } Instanciation de 3 objets AppliInstance obj1 = new AppliInstance( ); AppliInstance obj2 = newAppliInstance( ); AppliInstance obj3 = newAppliInstance( );
Voici une image du segment de mmoire associ ces 3 objets :
Exemple de variables de classe : class ApplistaticVar { public static int x =15 ; } La dfinition "static int x =15 ;" cre une variable de la classe ApplistaticVar, nomme x.
)
rm di Scala - 2006
page
31
class UtiliseApplistaticVar { int a ; void f( ) { a = ApplistaticVar.x ; ..... } }
L'instruction "a = ApplistaticVar.x ;" utilise la variable x comme variable de classe ApplistaticVar sans avoir instanci un objet de cette classe.
Nous pouvons utiliser la classe Math ( public sealed class Math ) qui contient des constantes et des fonctions mathmatiques courantes : public static const double E; // la constante e reprsente la base du logarithme nprien. public static const double PI; // la constante pi reprsente le rapport de la circonfrence d'un cercle son diamtre.
Mthode de classe Une mthode de classe est une mthode dont l'implmentation est la mme pour tous les objets de la classe, en fait la diffrence avec une mthode d'instance a lieu sur la catgorie des variables sur lesquelles ces mthodes agissent. De par leur dfinition les mthodes de classe ne peuvent travailler qu'avec des variables de classe, alors que les mthodes d'instances peuvent utiliser les deux catgories de variables. Un programme correct illustrant le discours : C#
class Exemple { public static int x ; int y ; public void f1(int a) { x = a; y = a; } public static void g1(int a) { x = a; } } class Utilise { public static void Main( ) { Exemple obj = new Exemple( ); obj.f1(10); System.Console.WriteLine("<f1(10)>obj.x="+ Exemple.x); Exemple.g1(50); System.Console.WriteLine("<g1(50)>obj.x="+ Exemple.x); } }
Explications
public void f1(int a) { x = a; //accs la variable de classe y = a ; //accs la variable d'instance } public static void g1(int a) { x = a; //accs la variable de classe y = a ; //engendrerait un erreur de compilation : accs une variable non static interdit ! } La mthode f1 accde toutes les variables de la classe Exemple, la mthode g1 n'accde qu'aux variables de classe (static et public). Aprs excution on obtient : <f1(10)>obj.x = 10 <g1(50)>obj.x = 50
page
32
Rsum pratique sur les membres de classe en C#

1) - Les mthodes et les variables de classe sont prcdes obligatoirement du mot clef static. Elles jouent un rle semblable celui qui est attribu aux variables et aux sousroutines globales dans un langage impratif classique.
C# class Exemple1 { int a = 5; static int b = 19; void m1( ){...} static void m2( ) {...} }
Explications La variable a dans int a = 5; est une variable d'instance. La variable b dans static int b = 19; est une variable de classe. La mthode m2 dans static void m2( ) {...} est une mthode de classe.
2) - Pour utiliser une variable x1 ou une mthode meth1 de la classe Classe1, il suffit de d'crire Classe1.x1 ou bien Classe1.meth1.
C# class Exemple2 { public static int b = 19; public static void m2( ) {...} } class UtiliseExemple { Exemple2.b = 53; Exemple2.m2( ); ... }
Explications Dans la classe Exemple2, b est une variable de classe, m2 une mthode de classe. La classe UtiliseExemple fait appel la mthode m2 directement avec le nom de la classe, il en est de mme avec le champ b de la classe Exemple2
rm di Scala - 2006
page
33
3) - Une variable de classe (prcde du mot clef static) est partage par tous les objets de la mme classe.
C#
class AppliStatic { public static int x = -58 ; public int y = 20 ; ... } class Utilise { public static void Main(String [ ] arg) { AppliStatic obj1 = new AppliStatic( ); AppliStatic obj2 = new AppliStatic( ); AppliStatic obj3 = new AppliStatic( ); obj1.y = 100; AppliStatic.x = 101; System.Console.WriteLine("obj1.x="+ AppliStatic.x); System.Console.WriteLine("obj1.y="+obj1.y); System.Console.WriteLine("obj2.x="+ AppliStatic.x); System.Console.WriteLine("obj2.y="+obj2.y); System.Console.WriteLine("obj3.x="+ AppliStatic.x); System.Console.WriteLine("obj3.y="+obj3.y); AppliStatic.x = 99; System.Console.WriteLine("AppliStatic.x=" + AppliStatic.x); } }
Explications
Dans la classe AppliStatic x est une variable de classe, et y une variable d'instance. La classe Utilise cre 3 objets (obj1,obj2,obj3) de classe AppliStatic. L'instruction obj1.y = 100; est un accs au champ y de l'instance obj1. Ce n'est que le champ y de cet objet qui est modifi,les champs y des objets obj2 et obj3 restent inchangs Il ny a quune seule manire d'accder la variable static x, comme pour toute variable de classe, en utilisant le nom de la classe : AppliStatic.x = 101; Dans ce cas cette variable x est modifie globalement et donc tous les champs x de tous les objets obj1, obj2 et obj3 prennent la nouvelle valeur.
Au dbut lors de la cration des 3 objets, chacun des champs x vaut -58 et chacun des champs y vaut 20, l'affichage par System.Console.WriteLine(...) donne les rsultats suivants qui dmontrent le partage de la variable x par tous les objets. Aprs excution : obj1.x = 101 obj1.y = 100 obj2.x = 101 obj2.y = 20 obj3.x = 101 obj3.y = 20 AppliStatic.x = 99
4) - Une mthode de classe (prcde du mot clef static) ne peut utiliser que des variables de classe (prcdes du mot clef static) et jamais des variables d'instance.Une mthode d'instance peut accder aux deux catgories de variables
5) - Une mthode de classe (prcde du mot clef static) ne peut appeler (invoquer) que des mthodes de classe (prcdes du mot clef static).
page
34
C#
class AppliStatic { public static int x = -58 ; public int y = 20 ; public void f1(int a) { AppliStatic.x = a; y=6; } } class Utilise { static void f2(int a) { AppliStatic.x = a; } public static void Main( ) { AppliStatic obj1 = new AppliStatic( ); AppliStatic obj2 = new AppliStatic( ); AppliStatic obj3 = new AppliStatic( ); obj1.y = 100; obj1.x = 101; AppliStatic.x = 99; f2(101); obj1.f1(102); } }
Explications
Nous reprenons l'exemple prcdent en ajoutant la classe AppliStatic une mthode interne f1 : public void f1(int a) { AppliStatic.x = a; y=6; } Cette mthode accde la variable de classe comme un champ d'objet. Nous rajoutons la classe Utilise, un mthode static (mthode de classe) note f2: static void f2(int a) { AppliStatic.x = a; } Cette mthode accde elle aussi la variable de classe parce qu c'est une mthode static. Nous avons donc trois manires d'accder la variable static x, : soit directement comme une variable de classe proprement dite : AppliStatic.x = 99; soit indirectement par une mthode d'instance sur son champ : obj1.f1(102); soit indirectement par une mthode static (de classe) : f2(101);
Comme la mthode Main est static, elle peut invoquer la mthode f2 qui est aussi static.
Au paragraphe prcdent, nous avons indiqu que C# ne connaissait pas la notion de variable globale stricto sensu, mais en fait une variable static peut jouer le rle d'un variable globale pour un ensemble d'objets instancis partir de la mme classe.
Attention :
Contrairement Java qui autorise laccs une variable static partir dun nom dobjet la place du nom de la classe de dfinition, le compilateur C# impose une cohrence dans les dclarations, en refusant cette possibilit.
rm di Scala - 2006
page
35
Polymorphisme d'objet en
Plan gnral:
Rappel des notions de base Polymorphisme d'objet en C# : dfinitions

1.1 Instanciation et utilisation dans le mme type 1.2 Polymorphisme d'objet implicite 1.3 Polymorphisme d'objet explicite par transtypage 1.4 Utilisation pratique du polymorphisme d'objet 1.5 Instanciation dans un type ascendant impossible
page
36
Le polymorphisme en C#
Rappel utile sur les notions de bases Il existe un concept essentiel en POO dsignant la capacit d'une hirarchie de classes fournir diffrentes implmentations de mthodes portant le mme nom et par corollaire la capacit qu'ont des objets enfants de modifier les comportements hrits de leur parents. Ce concept d'adaptation diffrentes "situations" se dnomme le polymorphisme qui peut tre implment de diffrentes manires.
Polymorphisme d'objet C'est une interchangeabilit entre variables d'objets de classes de la mme hirarchie sous certaines conditions, que dnommons le polymorphisme d'objet.
Polymorphisme par hritage de mthode Lorsqu'une classe enfant hrite d'une classe mre, des mthodes supplmentaires nouvelles peuvent tre implmentes dans la classe enfant mais aussi des mthodes des parents peuvent tre substitues pour obtenir des implmentations diffrentes.
Polymorphisme par hritage de classes abstraites Une classe abstraite est une classe qui ne peut pas s'instancier elle-mme ; elle doit tre hrite. Certains membres de la classe peuvent ne pas tre implments, et c'est la classe qui hrite de fournir cette implmentation.
Polymorphisme par implmentation d'interfaces Une interface dcrit la signature complte des membres qu'une classe doit implmenter, mais elle laisse l'implmentation de tous ces membres la charge de la classe d'implmentation de l'interface.
Polymorphisme d'objet en C# Soit une classe Mere et une classe Fille hritant de la classe Mere :
rm di Scala - 2006
page
37
Les objets peuvent avoir des comportements polymorphes (s'adapter et se comporter diffrement selon leur utilisation) licites et des comportements polymorphes dangereux selon les langages. Dans un langage dont le modle objet est la rfrence (un objet est un couple : rfrence, bloc mmoire) comme C#, il y a dcouplage entre les actions statiques du compilateur et les actions dynamiques du systme d'excution, le compilateur protge statiquement des actions dynamiques sur les objets une fois crs. C'est la dclaration et l'utilisation des variables de rfrences qui autorise ou non les actions licites grce la compilation. Supposons que nous ayons dclar deux variables de rfrence, l'une de classe Mere, l'autre de classe Fille, une question qui se pose est la suivante : au cours du programme quelle genre d'affectation et d'instanciation est-on autoris effectuer sur chacune de ces variables dans un programme C#.
En C# : public class Mere { ..... } public class Fille : Mere { ..... }
L'hritage permet une variabilit entre variables d'objets de classes de la mme hirarchie, c'est cette variabilit que dnommons le polymorphisme d'objet.
Nous envisageons toutes les situations possibles et les valuons, les exemples explicatifs sont crits en C# (lorsqu'il y a discordance avec java ou Delphi autres langages, celle-ci est mentionne explicitement), il existe 3 possibilits diffrentes illustres par le schma cidessous.
page
38
L'instanciation et l'utilisation de rfrences dans le mme type L'affectation de rfrences : polymorphisme implicite L'affectation de rfrences : polymorphisme par transtypage d'objet La dernire de ces possibilits pose un problme d'excution lorsqu'elle mal employe !
1.1 instanciation dans le type initial et utilisation dans le mme type

Il s'agit ici d'une utilisation la plus classique qui soit, dans laquelle une variable de rfrence d'objet est utilise dans son type de dfinition initial (valable dans tous les LOO)
En C# : Mere x , u ; Fille y , w ; ..... x = new Mere( ) ; // instanciation dans le type initial u = x ; // affectation de rfrences du mme type y = new Fille( ) ; // instanciation dans le type initial v = y ; // affectation de rfrences du mme type
rm di Scala - 2006
page
39
1.2 Polymorphisme d'objet implicite
En C# : Mere x ; Fille ObjF = new Fille( ) ; x = ObjF; // affectation de rfrences du type descendant implicite
Nous pouvons en effet dire que x peut se rfrer implicitement tout objet de classe Mere ou de toute classe hritant de la classe Mere.
fig - 1
fig - 2
page
40
Dans la figure fig-1 ci-dessus, une hirarchie de classes decendant toutes de la classe Mere, dans fig-2 ci-contre le schma montre une rfrence de type Mere qui peut 'pointer' vers n'importe quel objet de classe descendante (polymorphisme d'objet). D'une faon gnrale vous pourrez toujours crire des affectations entre deux rfrences d'objets :
En C# : Classe1 x ; Classe2 y ; .......... x=y; si et seulement si Classe2 est une classe descendante de Classe1.
Exemple pratique tir du schma prcdent 1) Le polymorphisme d'objet est typiquement fait pour reprsenter des situations pratiques figures ci-dessous :
Une hirarchie de classe de vhicules descendant toutes de la classe mre Vehicule, on peut noncer le fait suivant : Un vhicule peut tre de plusieurs sortes : soit un croiseur, soit une voiture, soit un vhicule terrestre etc... Traduit en termes informatiques, si l'on dclare une rfrence de type vhicule (vehicule x) elle pourra pointer vers n'importe quel objet d'une des classe filles de la classe vehicule.
En C# : public class Vehicule { .......... } public class terrestre : Vehicule{ .......... } public class voiture : terrestre { .......... }
rm di Scala - 2006
public class marin : Vehicule { .......... } public class voilier : marin { .......... } public class croiseur : marin { .......... }
page
41
Mettons en oeuvre la dfinition du polymorphisme implicite : Polymorphisme implicite = cration d'objet de classe descendante rfrenc par une variable parent Ajoutons 2 classes la hirarchie des vhicules :
Partons de la situation pratique suivante : on cre un vhicule du type voiture , on cre une voiture de type berline , enfin on cre un break de type break
Traduit en termes informatiques : nous dclarons 3 rfrences x, y et z de type vehicule, voiture et break et nous crons 3 objets de classe voiture, berline et break. Comme il est possible de crer directement un objet de classe descendante partir d'une rfrence de classe mre, nous proposons les instanciations suivantes : on cre une voiture rfrence par la variable de classe vehicule, on cre une berline rfrence par la variable de classe voiture, enfin on cre un break rfrenc par la variable de classe break.
page
42
En C# : public class berline : voiture { .......... } public class break : voiture { .......... }
public class Fabriquer { Vehicule x = new voiture ( ) ; voiture y = new berline ( ) ; break z = new break ( ); .......... }
1.3 Polymorphisme d'objet explicite par transtypage

La situation informatique est la suivante : on dclare une variable x de type Mere, on dclare une variable y de type Fille hritant de Mere, on instancie la variable x dans le type descendant Fille (polymorphisme implicite).
Il est alors possible de faire "pointer" la variable y (de type Fille) vers l'objet (de type Fille) auquel se rfre x en effectuant une affectation de rfrences : y = x ne sera pas accepte directement car statiquement les variables x et y ne sont pas du mme type, il faut indiquer au compilateur que l'on souhaite temporairement changer le type de la variable x afin de pouvoir effectuer l'affectation. Cette opration de changement temporaire, se dnomme le transtypage ( note en C# : y = (Fille)x ) :
rm di Scala - 2006
page
43
En C# : Mere x ; Fille y ; Fille ObjF = new Fille( ) ; x = ObjF ; // x pointe vers un objet de type Fille y = (Fille) x ; // transtypage et affectation de rfrences du type ascendant explicite compatible dynamiquement.
Attention
La validit du transtypage n'est pas vrifie statiquement par le compilateur, donc si votre variable de rfrence pointe vers un objet qui n'a pas la mme nature que l'oprateur de transtypage, c'est lors de l'excution qu'il y aura production d'un message d'erreur indiquant le transtypage impossible. Il est donc impratif de tester l'appartenance la bonne classe de l'objet transtyper avant de le transtyper, les langages C#, Delphi et Java disposent d'un oprateur permettant de tester cette appartenance ou plutt l'appartenance une hirarchie de classes (oprateur is en C#). L'oprateur as est un oprateur de transtypage de rfrence d'objet semblable l'oprateur ( ). L'oprateur as fournit la valeur null en cas d'chec de conversion alors que l'oprateur ( ) lve une exception.
page
44
En C# : Mere x ; Fille y ; x = new Mere( ) ; // instanciation dans le type initial { affectation de rfrences du type ascendant explicite mais dangereuse si x est uniquement Mere : } y = (Fille)x ; <--- erreur lors de l'excution ici {affectation accepte statiquement mais refuse dynamiquement, car x pointe vers un objet de type Mere }
En reprenant l'exemple pratique prcdant de la hirarchie des vhicules :
Puisque x pointe vers un objet de type voiture toute variable de rfrence acceptera de pointer vers cet objet, en particulier la variable voiture aprs transtypage de la rfrence de x. En C# l'affectation s'crirait par application de l'oprateur de transtypage :
y = ( voiture ) x;
Pour pallier cet inconvnient de programmation pouvant lever des exceptions lors de l'excution, C# offre au programmeur la possibilit de tester l'appartenance d'un objet rfrenc par une variable quelconque une classe ou plutt une hirarchie de classe ; en C# cet oprateur se dnote is : L'oprateur "is" de C# est identique celui de Delphi : L'oprateur is, qui effectue une vrification de type dynamique, est utilis pour vrifier quelle est effectivement la classe d'un objet l'excution. L'expression : objet is classeT renvoie True si objet est une instance de la classe dsigne par classeT ou de l'un de ses descendants, et False sinon. Si objet a la valeur nil, le rsultat est False.
rm di Scala - 2006
page
45
En C# : Mere x ; Fille y ; x = new Mere( ) ; // instanciation dans le type initial if ( x is Fille) // test d'appartenance de l'objet rfrenc par x la bonne classe y = (Fille)x ;
1.4 Utilisation pratique du polymorphisme d'objet

Le polymorphisme d'objet associ au transtypage est trs utile dans les paramtres des mthodes.
Lorsque vous dclarez une mthode meth avec un paramtre formel x de type ClasseT : void meth ( ClasseT x ); { ........ } Vous pouvez utiliser lors de l'appel de la mthode meth n'importe quel paramtre effectif de ClasseT ou bien d'une quelconque classe descendant de ClasseT et ensuite l'intrieur de la procdure vous transtypez le paramtre. Cet aspect est utilis en particulier en C# lors de la cration de gestionnaires d'vnements communs plusieurs composants :
private void meth1(object sender, System.EventArgs e) { if (sender is System.Windows.Forms.TextBox) (sender as TextBox).Text="Fin"; else if (sender is System.Windows.Forms.Label) (sender as Label).Text="ok"; // ou encore : if (sender is System.Windows.Forms.TextBox) ( (TextBox)sender ).Text="Fin"; else if (sender is System.Windows.Forms.Label) ( (Label)sender ).Text="ok";
Autre exemple avec une mthode meth2 personnelle sur la hirarchie des vhicules :
private void meth2 ( vehicule Sender ); { if (Sender is voiture) ((voiture)Sender). ....... ; else if (Sender is voilier) ((voilier)Sender). ....... ; ............ }
page
46
instanciation dans un type ascendant ( impossible en C#)

Il s'agit ici d'une utilisation non licite qui n'est pas commune tous les langages LOO. Le compilateur C# comme le compilateur Java, refuse ce type de cration d'objet, les compilateurs C++ et Delphi acceptent ce genre d'instanciation en laissant au programmeur le soin de se dbrouiller avec les problmes de cohrence lorsqu'ils apparatront.
rm di Scala - 2006
page
47
Polymorphisme de mthode en
Plan gnral:
1. Le polymophisme de mthodes en C#
Rappel des notions de base 1.1 Surcharge et redfinition en C# 1.2 Liaison statique et masquage en C# 1.3 Liaison dynamique en C# 1.4 Comment opre le compilateur Rsum pratique
2. Accs la super classe en C#

2.1 Le mot clef base 2.2 Initialiseur de constructeur this et base 2.3 Comparaison C#, Delphi et Java sur un exemple 2.4 Traitement d'un exercice complet
page
48
1. Le polymorphisme de mthode en C#
Nous avons vu au chapitre prcdent le polymorphisme d'objet, les mthodes peuvent tre elles aussi polymorphes. Nous avons vu comment Delphi mettait en oeuvre le polymorphisme d'objet et de mthode, nous voyons ici comment C# hrite une bonne part de Delphi pour ses comportements et de la souplesse de Java pour l'criture. Rappel de base
Polymorphisme par hritage de mthode

Lorsqu'une classe enfant hrite d'une classe mre, des mthodes supplmentaires nouvelles peuvent tre implmentes dans la classe enfant, mais aussi des mthodes des parents substitues pour obtenir des implmentations diffrentes. L'objectif vis en terme de qualiti du logiciel est la rutilisabilit en particulier lorsque l'on ralise une mme opration sur des lments diffrents : opration = ouvrir ( ) ouvrir une fentre de texte, ouvrir un fichier, ouvrir une image etc ...
Surcharge et redfinition avec C#

En informatique ce vocable s'applique aux mthodes selon leur degr d'adaptabilit, nous distinguons alors deux dnominations :
le polymorphisme statique ou la surcharge de mthode le polymorphisme dynamique ou la redfinition de mthode ou encore la surcharge hrite.
1.1 Surcharge La surcharge de mthode (polymorphisme statique de mthode) est une fonctionnalit classique des langages trs volus et en particulier des langages orients objet dont C# fait partie; elle consiste dans le fait qu'une classe peut disposer de plusieurs mthodes ayant le mme nom, mais avec des paramtres formels diffrents ou ventuellement un type de retour diffrent. On dit alors que ces mthodes n'ont pas la mme signature
On rappelle que la signature d'une mthode est forme par l'en-tte de la mthode avec ses paramtres formels et leur type. Nous avons dj utilis cette fonctionnalit prcdement dans le paragraphe sur les constructeurs, o la classe Un disposait de quatre constructeurs surchargs (quatre signatures diffrentes du constructeur) :
class Un { int a; public Un ( ) { a = 100; }
rm di Scala - 2006
public Un (int b ) Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

)
page
49
{ a = b;
public Un (float b ) { a = (int)b; } public Un (int x , float y ) : this(y) { a += 100; } }
Mais cette surcharge est possible aussi pour n'importe quelle mthode de la classe autre que le constructeur.
Ci-contre deux exemplaires surchargs de la mthode ouvrir dans la classe PortesEtFenetres :
Le compilateur n'prouve aucune difficult lorsqu'il rencontre un appel l'une des versions surcharge d'une mthode, il cherche dans la dclaration de toutes les surcharges celle dont la signature (la dclaration des paramtres formels) concide avec les paramtres effectifs de l'appel. Remarque : Le polymorphisme statique (ou surcharge) de C# est syntaxiquement semblable celui de Java.
Programme C# excutable
class Un { public int a; public Un (int b ) { a = b; } public void f ( ) { a *=10; } public void f ( int x ) { a +=10*x; } public int f ( int x, char y ) { a = x+(int)y; return a; } } class AppliSurcharge { public static void Main(String [ ] arg) { Un obj = new Un(15); System.Console.WriteLine("<cration> a ="+obj.a); obj.f( ); System.Console.WriteLine("<obj.f()> a ="+obj.a); obj.f(2); System.Console.WriteLine("<obj.f()> a ="+obj.a); obj.f(50,'a'); System.Console.WriteLine("<obj.f()> a ="+obj.a); } }
Explications
La mthode f de la classe Un est surcharge trois fois : public void f ( ) { a *=10; } public void f ( int x ) { a +=10*x; } public int f ( int x, char y ) { a = x+(int)y; return a; } La mthode f de la classe Un peut donc tre appele par un objet instanci de cette classe sous l'une quelconque des trois formes : obj.f( ); pas de paramtre => choix : void f ( ) obj.f(2); paramtre int => choix : void f ( int x ) obj.f(50,'a'); deux paramtres, un int un char => choix : int f ( int x, char y )
page
50
Comparaison Delphi - C# sur la surcharge : Delphi

Un = class a : integer; public constructor methode( b : integer ); procedure f;overload; procedure f(x:integer);overload; function f(x:integer;y:char):integer;overload; end; implementation constructor Un.methode( b : integer ); begin a:=b end; procedure Un.f; begin a:=a*10; end; procedure Un.f(x:integer); begin a:=a+10*x end; function Un.f(x:integer;y:char):integer; begin a:=x+ord(y); result:= a end; procedure Main; var obj:Un; begin obj:=Un.methode(15); obj.f; Memo1.Lines.Add('obj.f='+inttostr(obj.a)); obj.f(2); Memo1.Lines.Add('obj.f(2)='+inttostr(obj.a)); obj.f(50,'a'); Memo1.Lines.Add('obj.f(50,''a'')='+inttostr(obj.a)); end; class Un { public int a; public Un (int b ) { a = b; } public void f ( ) { a *=10; } public void f ( int x ) { a +=10*x; } public int f ( int x, char y ) { a = x+(int)y; return a; } }
C#
class AppliSurcharge { public static void Main(String [ ] arg) { Un obj = new Un(15); System.Console.WriteLine("<cration> a ="+obj.a); obj.f( ); System.Console.WriteLine("<obj.f()> a ="+obj.a); obj.f(2); System.Console.WriteLine("<obj.f()> a ="+obj.a); obj.f(50,'a'); System.Console.WriteLine("<obj.f()> a ="+obj.a); } }
Redfinition
La redfinition de mthode (ou polymorphisme dynamique) est spcifique aux langages orients objet. Elle est mise en oeuvre lors de l'hritage d'une classe mre vers une classe fille dans le cas d'une mthode ayant la mme signature dans les deux classes. Dans ce cas les actions des l'appel de la mthode, dpendent du code inhrent chaque version de la mthode (celle de la classe mre, ou bien celle de la classe fille). Dans l'exemple ci-dessous, nous supposons que dans la classe PortesEtFenetres la mthode ouvrir(fenetre) explique le mode opratoire gnral d'ouverture d'une fentre, il est clair que dans les deux classes descendantes l'on doit "redfinir" le mode opratoire selon que l'on est en prsence d'une fentre la franaise, ou une fentre l'anglaise :
rm di Scala - 2006
page
51
Redfinition et rpartition des mthodes en C#

La redfinition de mthode peut tre selon les langages :
prcoce
et/ou
tardive
Ces deux actions sont diffrentes selon que le compilateur du langage met en place la laison du code de la mthode immdiatement lors de la compilation (liaison statique ou prcoce) ou bien lorsque le code est li lors de l'excution (laison dynamique ou tardive). Ce phnomne se dnomme la rpartition des mthodes. Le terme de rpartition fait rfrence la faon dont un programme dtermine o il doit rechercher une mthode lorsqu'il rencontre un appel cette mthode. Le code qui appelle une mthode ressemble un appel classique de mthode. Mais les classes ont des faons diffrentes de rpartir les mthodes.
Le langage C# supporte d'une manire identique Delphi, ces deux modes de liaison du code, la liaison statique tant comme en Delphi le mode par dfaut. Le dveloppeur Java sera plus dcontenanc sur ce sujet, car la liaison statique en Java n'existe que pour les methodes de classe static, de plus la liaison du code par dfaut est dynamique en Java.
Donc en C# comme en Delphi, des mots clefs comme virtual et override sont ncessaires pour la redfinition de mthode, ils sont utiliss strictement de la mme manire qu'en Delphi.
page
52
1.2 Liaison statique et masquage en C# Toute mthode C# qui n'est prcde d'aucun des deux qualificateurs virtual ou override est liaison statique. Le compilateur dtermine l'adresse exacte de la mthode et lie la mthode au moment de la compilation. L'avantage principal des mthodes statiques est que leur rpartition est trs rapide. Comme le compilateur peut dterminer l'adresse exacte de la mthode, il la lie directement (les mthodes virtuelles, au contraire, utilisent un moyen indirect pour rcuprer l'adresse des mthodes l'excution, moyen qui ncessite plus de temps). Une mthode statique ne change pas lorsqu'elle est transmise en hritage une autre classe. Si vous dclarez une classe qui inclut une mthode statique, puis en drivez une nouvelle classe, la classe drive partage exactement la mme mthode situe la mme adresse. Cela signifie qu'il est impossible de redfinir les mthodes statiques; une mthode statique fait toujours exactement la mme chose, quelque soit la classe dans laquelle elle est appele. Si vous dclarez dans une classe drive une mthode ayant le mme nom qu'une mthode statique de la classe anctre, la nouvelle mthode remplace simplement (on dit aussi masque) la mthode hrite dans la classe drive. Comparaison masquage en Delphi et C# : Delphi
type ClasseMere = class x : integer; procedure f (a:integer); end; ClasseFille = class ( ClasseMere ) y : integer; procedure f (a:integer);//masquage end; implementation procedure ClasseMere.f (a:integer); begin... end; procedure ClasseFille.f (a:integer); begin... end;
C#
public class ClasseMere { int x = 10; public void f ( int a) { x +=a; } } public class ClasseFille : ClasseMere { int y = 20; public void f ( int a) //masquage { x +=a*10+y; } }
Remarque importante : L'exprience montre que les tudiants comprennent immdiatement le masquage lorsque le polymorphisme d'objet n'est pas prsent. Ci-dessous un exemple de classe UtiliseMereFille qui instancie et utilise dans le mme type un objet de classe ClasseMere et un objet de classe ClasseFille :
rm di Scala - 2006
page
53
Lors de la compilation de l'instruction M.meth(10), c'est le code de la mthode meth de la classe ClasseMere qui est li avec comme paramtre par valeur 10; ce qui donnera la valeur 11 au champ x de l'objet M. Lors de la compilation de l'instruction F.meth(10), c'est le code de la mthode meth de la classe ClasseFille qui masque celui de la classe parent et qui est donc li avec comme paramtre par valeur 10; ce qui donnera la valeur 101 au champ x de l'objet F.
Pour bien comprendre toute la porte du masquage statique et les risques de mauvaises interprtations, il faut tudier le mme exemple lgrement modifi en incluant le cas du polymorphisme d'objet, plus prcisment le polymorphisme d'objet implicite. Dans l'exemple prcdent nous instancions la variable ClasseMere M en un objet de classe ClasseFille (polymorphisme implicite d'objet) soient les instructions ClasseMere M ; M = new ClasseFille ( ) ;
Une erreur courante est de croire que dans ces conditions, dans l'instruction M.meth(10) c'est la mthode meth(int a) de la classe ClasseFille (en particulier si l'on ne connat que Java qui ne pratique pas le masquage) :
page
54
Que fait alors le compilateur C# dans ce cas ? : il ralise une liaison statique : Lors de la compilation de l'instruction M.meth(10), c'est le code de la mthode meth(int a) de la classe ClasseMere qui est li, car la rfrence M a t dclare de type ClasseMere et peu importe dans quelle classe elle a t instancie ( avec comme paramtre par valeur 10; ce qui donnera la valeur 11 au champ x de l'objet M). Lors de la compilation de l'instruction F.meth(10), c'est le code de la mthode meth de la classe ClasseFille comme dans l'exemple prcdent (avec comme paramtre par valeur 10; ce qui donnera la valeur 101 au champ x de l'objet F).
rm di Scala - 2006
page
55
Voici la bonne configuration de laison effectue lors de la compilation :
Afin que le programmeur soit bien conscient d'un effet de masquage d'une mthode hrite par une mthode locale, le compilateur C# envoie, comme le compilateur Delphi, un message d'avertissement indiquant une possibilit de manque de cohrence smantique ou un masquage. S'il s'agit d'un masquage voulu, le petit plus apport par le langage C# est la proposition que vous fait le compilateur de l'utilisation optionnelle du mot clef new qualifiant la nouvelle mthode masquant la mthode parent. Cette criture amliore la lisibilit du programme et permet de se rendre compte que l'on travaille avec une liaison statique. Ci-dessous deux critures quivalentes du masquage de la mthode meth de la classe ClasseMere : masquage C#
public class ClasseMere { int x = 10; public void meth ( int a) //liaison statique { x +=a; } } public class ClasseFille : ClasseMere { public void meth ( int a) //masquage { x +=a*10+y; } }
masquage C# avec new

public class ClasseMere { int x = 10; public void meth ( int a) //liaison statique { x +=a; } } public class ClasseFille : ClasseMere { public new void meth ( int a) //masquage { x +=a*10+y; } }
)
page
56
L'exemple ci-dessous rcapitule les notions de masquage et de surcharge en C# : public class ClasseMere { int x = 1; public void meth1 ( int a) { x += a ; } public void meth1 ( int a , int b) { x += a*b ; } } public class ClasseFille : ClasseMere { public new void meth1 ( int a) { x += a*100 ; } public void meth1 ( int a , int b , int c) { x += a*b*c ; } } public class UtiliseMereFille { public static void Main (string [ ] args) { ClasseMere M ; ClasseFille F ; M = new ClasseFille ( ) ; F = new ClasseFille ( ) ; M.meth1 (10) ; <--- meth1(int a) de ClasseMere M.meth1 (10,5) ; <--- meth1(int a, int b) de ClasseMere M.meth1 (10,5,2) ; <--- erreur! n'existe pas dans ClasseMere . F.meth1 (10) ; <--- meth1(int a) de ClasseFille F.meth1 (10,5) ; <--- meth1(int a, int b) de ClasseFille F.meth1 (10,5,2) ; <--- meth1(int a, int b, int c) de ClasseFille } 1.3 Liaison dynamique (ou redfinition) en C# Dans l'exemple ci-dessous la classe ClasseFille qui hrite de la classe ClasseMere, redfini la mthode f de sa classe mre : Comparaison redfinition Delphi et C# : Delphi
type ClasseMere = class x : integer; procedure f (a:integer);virtual;//autorisation procedure g(a,b:integer); end; ClasseFille = class ( ClasseMere ) y : integer; procedure f (a:integer);override;//redfinition procedure g1(a,b:integer); end; implementation
rm di Scala - 2006
C#
class ClasseMere { int x = 10; public virtual void f ( int a) { x +=a; } void g ( int a, int b) { x +=a*b; } } class ClasseFille extends ClasseMere { int y = 20;
page
57
procedure ClasseMere.f (a:integer); begin... end; procedure ClasseMere.g(a,b:integer); begin... end; procedure ClasseFille.f (a:integer); begin... end; procedure ClasseFille.g1(a,b:integer); begin... end;
public override void f ( int a) //redfinition { x +=a; } void g1 (int a, int b) //nouvelle mthode { ...... } }
Comme delphi, C# peut combiner la surcharge et la redfinition sur une mme mthode, c'est pourquoi nous pouvons parler de surcharge hrite : C#
class ClasseMere { public int x = 10; public virtual void f ( int a) { x +=a; } public virtual void g ( int a, int b) { x +=a*b; } } class ClasseFille : ClasseMere { int y = 20; public override void f ( int a) //redfinition { x +=a; } public virtual void g (char b) //surcharge de g { x +=b*y; } }
1.4 Comment opre le compilateur C# C'est le compilateur C# qui fait tout le travail de recherche de la bonne mthode. Prenons un objet obj de classe Classe1, lorsque le compilateur C# trouve une instruction du genre "obj.method1(paramtres effectifs);", sa dmarche d'analyse est semblable celle du compilateur Delphi, il cherche dans l'ordre suivant : Y-a-t-il dans Classe1, une mthode qui se nomme method1 ayant une signature identique aux paramtres effectifs ? si oui c'est la mthode ayant cette signature qui est appele, si non le compilateur remonte dans la hierarchie des classes mres de Classe1 en posant la mme question rcursivement jusqu' ce qu'il termine sur la classe Object. Si aucune mthode ayant cette signature n'est trouve il signale une erreur.
Soit partir de l'exemple l'exemple prcdent les instructions suivantes :

)
page
58
ClasseFille obj = new ClasseFille( ); obj.g(-3,8); obj.g('h'); Le compilateur C# applique la dmarche d'analyse dcrite, l'instruction "obj.g(-3,8);". Ne trouvant pas dans ClasseFille de mthode ayant la bonne signature (signature = deux entiers) , le compilateur remonte dans la classe mre ClasseMere et trouve une mthode " void g ( int a, int b) " de la classe ClasseMere ayant la bonne signature (signature = deux entiers), il procde alors l'appel de cette mthode sur les paramtres effectifs (-3,8). Dans le cas de l'instruction obj.g('h'); , le compilateur trouve immdiatement dans ClasseFille la mthode " void g (char b) " ayant la bonne signature, c'est donc elle qui est appele sur le paramtre effectif 'h'. Le compilateur consulte les mta-donnes (informations de description) de l'assemblage en cours ( applicationXXX.exe ), plus particulirement les mtadonnes de type qui sont stockes au fur et mesure dans de nombreuses tables. Nous figurons ci-dessous deux tables de dfinition importantes relativement au polymorphisme de mthode MethodDef et TypeDef utilises par le compilateur.
rm di Scala - 2006
page
59
Rsum pratique sur le polymorphisme en C#

La surcharge (polymorphisme statique) consiste proposer diffrentes signatures de la mme mthode. La redfinition (polymorphisme dynamique) ne se produit que dans l'hritage d'une classe, par redfinition (liaison dynamique) de la mthode mre avec une mthode fille (ayant ou n'ayant pas la mme signature). Le masquage ne se produit que dans l'hritage d'une classe, par redfinition (liaison statique) de la mthode mre par une mthode fille (ayant la mme signature). Toute mthode est considre liaison statique sauf si vous la dclarez autrement.
2. Accs la super classe en C#

2.1 Le mot clef base Nous venons de voir que le compilateur s'arrte ds qu'il trouve une mthode ayant la bonne signature dans la hirarchie des classes, il est des cas o nous voudrions accder une mthode de la classe mre alors que celle-ci est redfinie dans la classe fille. C'est un problme analogue l'utilisation du this lors du masquage d'un attribut. classe mre
class
classe fille class ClasseB : ClasseA { public new void meth01 ( ) { attrA = 1000 ; } public void meth02 ( ) { meth01 ( ); } }
ClasseA
{ public int attrA ; private int attrXA ; public void meth01 ( ) { attrA = 57 ; } }
La mthode meth02 ( ) invoque la mthode meth01 ( ) de la classe ClasseB. Il est impossible de faire directement appel la mthode meth01 ( ) de la classe mre ClasseA car celle-ci est masque dans la classe fille.
page
60
Il existe en C# un mcanisme dclench par un mot clef qui permet d'accder la classe mre (classe immdiatement au dessus): ce mot est base. Le mot clef base est utilis pour accder tous les membres visibles de la classe mre partir d'une classe fille drive directement de cette classe mre ( la super-classe en Java).
Ce mot clef base est trs semblable au mot clef inherited de Delphi qui joue le mme rle sur les mthodes et les proprits (il est en fait plus proche du mot clef super de Java car il ne remonte qu' la classe mre), il permet l'appel d'une mthode de la classe de base qui a t substitue (masque ou redfinie) par une autre mthode dans la classe fille. Exemple :
Remarques : Le fait d'utiliser le mot clef base partir d'une mthode statique constitue une erreur. base est utile pour spcifier un constructeur de classe mre lors de la cration d'instances de la classe fille.
Nous dveloppons ci-dessous l'utilisation du mot clef base afin d'initialiser un constructeur.
rm di Scala - 2006
page
61
2.2 Initialiseur de constructeur this et base Semblablement Delphi et Java, tous les constructeurs d'instance C# autorisent l'appel d'un autre constructeur d'instance immdiatement avant le corps du constructeur, cet appel est dnomm l'initialiseur du constructeur, en Delphi cet appel doit tre explicite, en C# et en Java cet appel peut tre implicite. Rappelons que comme en Java o dans toute classe ne contenant aucun constructeur, en C# un constructeur sans paramtres par dfaut est implicitement dfini :
vous crivez votre code comme ceci : class ClasseA { public int attrA ; public string attrStrA ; }
il est complt implicitement ainsi : class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { } }
Remarque : Lors de l'hritage d'une classe fille, diffremment Delphi et Java, si un constructeur d'instance C# de la classe fille ne fait pas figurer explicitement d'initialiseur de constructeur, c'est qu'en fait un initialiseur de constructeur ayant la forme base( ) lui a t fourni implicitement.
Soit par exemple une classe ClasseA possdant 2 constructeurs :

class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { /* premier constructeur */ attrA = 57 ; } public ClasseA ( string s ) { /* second constructeur */ attrStrA = s +"...1..." ; } }
Soit par suite une classe fille ClasseB drivant de ClasseA possdant elle aussi 2 constructeurs, les deux dclarations ci-dessous sont quivalentes :
page
62
Initialiseur implicite class ClasseB : ClasseA { /* premier constructeur */ public ClasseB ( ) { attrStrA = "..." ; } /* second constructeur */ public ClasseB ( string s ) { attrStrA = s ; } }
Initialiseur explicite quivalent class ClasseB : ClasseA { /* premier constructeur */ public ClasseB ( ) : base( ) { attrStrA = "..." ; } /* second constructeur */ public ClasseB ( string s ) : base( ) { attrStrA = s ; } }
Dans les deux cas le corps du constructeur de la classe fille est initialis par un premier appel au constructeur de la classe mre ( ), en l'occurrence << public ClasseA ( ) ... /* premier constructeur */ >> Remarque : De mme pour une classe fille, C# comme Java, tout constructeur de la classe fille appelle implicitement et automatiquement le constructeur par dfaut (celui sans paramtres) de la classe mre.
Exemple : vous crivez votre code comme ceci : class ClasseA { public int attrA ; public string attrStrA ; } class ClasseB : ClasseA { } } Le constructeur de ClasseA sans paramtres est implicitement dclar par le compilateur. class ClasseB : ClasseA { public ClasseB ( ): base( ) { } } il est complt implicitement ainsi : class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { }
Si la classe mre ne possde pas de constructeur par dfaut, le compilateur engendre un message d'erreur :
rm di Scala - 2006
page
63
vous crivez votre code comme ceci : class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( int a ) { } class ClasseB : ClasseA { public ClasseB ( ) { //..... } }
La classe de base ClasseA ne comporte qu'un seul constructeur explicite un paramtre. Le constructeur sans paramtres n'existe que si vous le dclarez explicitement, ou bien si la classe ne possde pas de constructeur explicitement dclar.
il est complt implicitement ainsi : class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( int a ) { } } class ClasseB : ClasseA { public ClasseB ( ): base( ) { // .... } }
L'initialiseur implicite base( ) renvoie le compilateur chercher dans la classe de base un constructeur sans paramtres. Or il n'existe pas dans la classe de base (ClasseA) de constructeur par dfaut sans paramtres. Donc la tentative choue !
Le message d'erreur sur la ligne " public ClasseB ( ) { ", est le suivant : [C# Erreur] Class.cs(54): Aucune surcharge pour la mthode 'ClasseA' ne prend d'arguments '0' Remarques : Donc sans initialiseur explicite, tout objet de classe fille ClasseB est minima et par dfaut, instanci comme un objet de classe de base ClasseA. Lorsque l'on veut invoquer dans un constructeur d'une classe donne un autre constructeur de cette mme classe tant donn que tous les constructeurs ont le mme nom, il faut utiliser le mot clef this comme nom d'appel.
Exemple : Reprenons la mme classe ClasseA possdant 2 constructeurs et la classe ClasseB drivant de ClasseA, nous marquons les actions des constructeurs par une chane indiquant le numro du constructeur invoqu ainsi que sa classe : class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { /* premier constructeur */ attrA = 57 ; } public ClasseA ( string s ) { /* second constructeur */ attrStrA = s +"...classeA1..." ;
)
page
64
} } Ci-dessous la ClasseB crite de deux faons quivalentes : avec initialiseurs implicites-explicites

class ClasseB : ClasseA { /* premier constructeur */ public ClasseB ( ) { attrA = 100+attrA ; } /* second constructeur */ public ClasseB ( string s ) { attrStrA = attrStrA +s+"...classeB2..." ; } /* troisime constructeur */ public ClasseB ( int x , string ch ) : this( ch ) { attrStrA = attrStrA+"...classeB3..." ; } /* quatrime constructeur */ public ClasseB ( char x , string ch ) : base( ch ) { attrStrA = attrStrA+"...classeB4..." ; } }
avec initialiseurs explicites quivalents

class ClasseB : ClasseA { /* premier constructeur */ public ClasseB ( ) : base( ) { attrA = 100+attrA ; } /* second constructeur */ public ClasseB ( string s ): base( ) { attrStrA = attrStrA +s+"...classeB2..." ; } /* troisime constructeur */ public ClasseA ( int x , string ch ) : this( ch ) { attrStrA = attrStrA+"...classeB3..." ; } /* quatrime constructeur */ public ClasseB ( char x , string ch ) : base( ch ) { attrStrA = attrStrA+"...classeB4..." ; } }
Crons quatre objets de ClasseB, chacun avec l'un des 4 constructeurs de la ClasseB : class MaClass { static void Main(string[] args) { int x=68; ClasseB ObjetB= new ClasseB( ); System.Console.WriteLine(ObjetB.attrA); ObjetB= new ClasseB(x,"aaa"); System.Console.WriteLine(ObjetB.attrStrA); ObjetB= new ClasseB((char)x,"bbb"); System.Console.WriteLine(ObjetB.attrStrA); ObjetB= new ClasseB("ccc"); System.Console.WriteLine(ObjetB.attrStrA); System.Console.ReadLine(); } }
rm di Scala - 2006
page
65
Voici le rsultat console de l'excution de ce programme :
Explications :
public ClasseB ( ) { attrA = 100+attrA ; } ClasseB ObjetB= new ClasseB( ); System.Console.WriteLine(ObjetB.attrA); C# slectionne la signature du premier constructeur de la ClasseB (le constructeur sans paramtres). C# appelle d'abord implicitement le constructeur sans paramtre de la classe mre ( : base( ) ) public ClasseA ( ) { attrA = 57 ; } Le champ attrA vaut 57, puis C# excute le corps du constructeur : attrA = 100+attrA ; attrA vaut 100+57 = 157 public ClasseB ( string s ) { attrStrA = attrStrA +s+"...classeB2..." ; } public ClasseB ( int x , string ch ) : this( ch ) { attrStrA = attrStrA+"...classeB3..." ; } ObjetB= new ClasseB(x,"aaa"); System.Console.WriteLine(ObjetB.attrStrA); C# slectionne la signature du troisime constructeur de la ClasseB (le constructeur avec paramtres : int x , string ch). C# appelle d'abord explicitement le constructeur local de la classeB avec un paramtre de type string ( le second constructeur de la ClasseB ) s = "aaa" ; public ClasseB ( string s ) { attrStrA = attrStrA +s+"...classeB2..." ; } Le champ attrStrA vaut "aaa...classeB2...", puis C# excute le corps du constructeur : attrStrA = attrStrA+"...classeB3..." ; attrStrA vaut "aaa...classeB2......classeB3..."
page
66
public ClasseB ( char x , string ch ) : base( ch ) { attrStrA = attrStrA+"...classeB4..." ; } ObjetB= new ClasseB((char)x,"bbb"); System.Console.WriteLine(ObjetB.attrStrA);
C# slectionne la signature du quatrime constructeur de la ClasseB (le constructeur avec paramtres : char x , string ch). C# appelle d'abord explicitement le constructeur de la classe mre (de base) classeA avec un paramtre de type string ( ici le second constructeur de la ClasseA ) s = "bbb" ; public ClasseA ( string s ) { attrStrA = s +"...classeA1..." ; } Le champ attrStrA vaut "bbb...classeA1..." puis C# excute le corps du constructeur : attrStrA = attrStrA+"...classeB4..." ; attrStrA vaut "bbb...classeA1......classeB4..."
La dernire instanciation : ObjetB= new ClasseB("ccc"); est strictement identique la premire mais avec appel au second constructeur.
2.3 Comparaison de construction C#, Delphi et Java Exemple classe mre : C#

class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { attrA = 57 ; } public ClasseA ( string s ) { attrStrA = s +"...classeA1..." ; } } }
Java
class ClasseA { public int attrA ; public String attrStrA = "" ; public ClasseA ( ) { attrA = 57 ; } public ClasseA ( String s ) { attrStrA = s +"...classeA1..." ; }
rm di Scala - 2006
page
67
C#
class ClasseA { public int attrA ; public string attrStrA ; public ClasseA ( ) { attrA = 57 ; } public ClasseA ( string s ) { attrStrA = s +"...classeA1..." ; } }
Delphi
ClasseA = class public attrA : integer ; attrStrA: string ; constructor Creer;overload; constructor Creer(s:string); overload; end; constructor ClasseA.Creer begin attrA := 57 ; end; constructor ClasseA.Creer(s:string); begin attrStrA := s +'...classeA1...' ; end;
Exemple classe fille : C# class ClasseB : ClasseA { /* premier constructeur */ public ClasseB ( ) { attrA = 100+attrA ; } /* second constructeur */ public ClasseB ( string s ) { attrStrA = attrStrA +s+"...classeB2..." ; } Java class ClasseB extends ClasseA { /* premier constructeur */ public ClasseB ( ) { super( ) ; attrA = 100+attrA ; } /* second constructeur */ public ClasseB ( String s ) { super( ) ; attrStrA = attrStrA +s+"...classeB2..." ; } /* troisime constructeur */ public ClasseB ( int x , String ch ) { this( ch ) ; attrStrA = attrStrA+"...classeB3..." ; } /* quatrime constructeur */ public ClasseB ( char x , String ch ) { super( ch ) ; attrStrA = attrStrA+"...classeB4..." ; } }
/* troisime constructeur */ public ClasseB ( int x , string ch ) : this( ch ) { attrStrA = attrStrA+"...classeB3..." ; }
/* quatrime constructeur */ public ClasseB ( char x , string ch ) : base( ch ) { attrStrA = attrStrA+"...classeB4..." ; } }
page
68
C#
class ClasseB : ClasseA {
Delphi
ClasseB = class( ClasseA ) public constructor Creer;overload; constructor Creer(s:string); overload; constructor Creer(x:integer;ch:string); overload; constructor Creer(x:char;ch:string); overload; end; /* premier constructeur */ constructor ClasseB.Creer; begin inherited ; attrA := 100+attrA ; end; /* second constructeur */ constructor ClasseB.Creer(s:string); begin inherited Creer ; attrStrA := attrStrA +s+'...classeB2...' ; end; /* troisime constructeur */ constructor ClasseB.Creer(x:integer;ch:string); begin Creer( ch ) ; attrStrA := attrStrA+'...classeB3...' ; end; /* quatrime constructeur */ constructor ClasseB.Creer(x:integer;ch:string); begin inherited Creer( ch ) ; attrStrA := attrStrA+'...classeB4...' ; end;
/* premier constructeur */ public ClasseB ( ) { attrA = 100+attrA ; } /* second constructeur */ public ClasseB ( string s ) { attrStrA = attrStrA +s+"...classeB2..." ; }
/* troisime constructeur */ public ClasseB ( int x , string ch ) : this( ch ) { attrStrA = attrStrA+"...classeB3..." ; }
/* quatrime constructeur */ public ClasseB ( char x , string ch ) : base( ch ) { attrStrA = attrStrA+"...classeB4..." ; } }
2.4 Traitement d'un exercice complet Soit une hirarchie de classe de vhicules :
rm di Scala - 2006
syntaxe de base :
)
page
69
class Vehicule { } class Terrestre :Vehicule { } class Marin :Vehicule { }
class Voiture : Terrestre { } class Voilier : Marin { } class Croiseur : Marin { }
Supposons que la classe Vhicule contienne 3 mthodes, qu'elle n'implmente pas la mthode Demarrer qui est alors abstraite, qu'elle fournit et implante vide la mthode "RpartirPassagers" de rpartition des passagers bord du vhicule, qu'elle fournit aussi et implante vide une mthode "PriodicitMaintenance" renvoyant la priodicit de la maintenance obligatoire du vhicule.
La classe Vhicule est abstraite : car la mthode Demarrer est abstraite et sert de "modle" aux futures classes drivant de Vhicule. Supposons que l'on implmente le comportement prcis du genre de dmarrage dans les classes Voiture , Voilier et Croiseur .
Dans cette hirarchie, les classes Terrestre et Marin hritent de la classe Vehicule, mais n'implmentent pas la mthode abstraite Dmarrer, ce sont donc par construction des classes abstraites elles aussi. Elles implantent chacune la mthode "RpartirPassagers" (fonction de la forme, du nombre de places, du personnel charg de s'occuper de faire fonctionner le vhicule...) et la mthode "PriodicitMaintenance" (fonction du nombre de km ou miles parcourus, du nombre d'heures d'activits,...) Les classes Voiture , Voilier et Croiseur savent par hritage direct comment rpartir leur ventuels passagers et quand effectuer une maintenance, chacune d'elle implmente son propre comportement de dmarrage.
page
70
Quelques implantations en C#
Une implmentation de la classe Voiture avec des mthodes non virtuelles (Version-1) :
abstract class Vehicule { public abstract void Demarrer( ); public void RpartirPassagers( ){} public void PriodicitMaintenance( ){} } La mthode Demarrer de la classe Vehicule est abstraite et donc automatiquement virtuelle ( liaison dynamique). Les mthodes RpartirPassagers et PriodicitMaintenance sont concrtes mais avec un corps vide. Ces deux mthodes sont non virtuelles ( liaison statique) abstract class Terrestre : Vehicule { public new void RpartirPassagers( ){ //...} public new void PriodicitMaintenance( ){ //...} } La classe Terrestre est abstraite car elle n'implmente pas la mthode abstraite Demarrer. Les deux mthodes dclares dans la classe Terrestre masquent chacune la mthode du mme nom de la classe Vehicule (d'o l'utilisation du mot clef new)
class Voiture : Terrestre { public override void Demarrer( ){ //...} }
La classe Voiture est la seule tre instanciable car toutes ses mthodes sont concrtes : Elle hrite des 2 mthodes implmentes de la classe Terrestre et elle implante (redfinition avec override) la mthode abstraite de l'anctre.
La mme implmentation de la classe Voiture avec des mthodes virtuelles (Version-2):

abstract class Vehicule { public abstract void Demarrer( ); public virtual void RpartirPassagers( ){} public virtual void PriodicitMaintenance( ){} } La mthode Demarrer de la classe Vehicule est abstraite et donc automatiquement virtuelle ( liaison dynamique). Les mthodesRpartirPassagers et PriodicitMaintenance sont concrtes mais avec un corps vide. Ces deux mthodes sont maintenant virtuelles ( liaison dynamique) abstract class Terrestre : Vehicule { public override void RpartirPassagers( ){ //...} public override void PriodicitMaintenance( ){ //...} } La classe Terrestre est abstraite car elle n'implmente pas la mthode abstraite Demarrer. Les deux mthodes dclares dans la classe Terrestre redfinissent chacune la mthode du mme nom de la classe Vehicule (d'o l'utilisation du mot clef override)
class Voiture : Terrestre { public override void Demarrer( ){ //...} }
La classe Voiture est la seule tre instanciable car toutes ses mthodes sont concrtes : Elle hrite des 2 mthodes implmentes de la classe Terrestre et elle implante (redfinition avec override) la mthode abstraite de l'anctre.
Supposons que les mthodes non virtuelles RpartirPassagers et PriodicitMaintenance sont implantes compltement dans la classe Vehicule, puis reprenons la classe Terrestre en masquant ces deux mthodes :
rm di Scala - 2006
page
71
abstract class Vehicule { public abstract void Demarrer( ); public void RpartirPassagers( ){ //....} public void PriodicitMaintenance( ){ //....} } abstract class Terrestre : Vehicule { public new void RpartirPassagers( ){ //...} public new void PriodicitMaintenance( ){ //...} } Question Nous voulons qu'un vhicule Terrestre rpartisse ses passagers ainsi : 1) d'abord comme tous les objets de classe Vehicule, 2) ensuite qu'il rajoute un comportement qui lui est propre Rponse La mthode RpartirPassagers est non virtuelle, elle masque la mthode mre du mme nom, si nous voulons accder au comportement de base d'un vhicule, il nous faut utiliser le mot clef base permettant d'accder aux membres de la classe mre : abstract class Terrestre : Vehicule { public new void RpartirPassagers( ){ base.RpartirPassagers( ); //... 1; comportement du parent //... 2 comportement propre } public new void PriodicitMaintenance( ){ //...} }
Il est conseill au lecteur de reprendre le mme schma et d'implanter l'identique les autres classes de la hirarchie pour la branche des vhicules Marin.
page
72
Polymorphisme et interfaces en
Plan gnral:
Rappels sur la notion d'interface
1.Concepts et vocabulaire d'interface en C#

les interfaces peuvent constituer des hirarchies et hriter entre elles la construction d'un objet necessite une classe implmentant l'interface les implmentations d'un membre d'interface sont en gnral public les implmentations explicites d'un membre d'interface sont spciales
1.1 Spcification d'un exemple complet 1.1.A Une classe abstraite 1.1.B Une interface 1.1.C Une simulation d'hritage multiple 1.1.D Encore une classe abstraite, mais plus concrte 1.1.E Une classe concrte 1.2 Implantation en C# de l'exemple 1.2.A La classe abstraite 1.2.B L'interface 1.2.C La simulation d'hritage multiple 1.2.D La nouvelle classe abstraite 1.2.E La classe concrte
2. Analyse du code de liaison de la solution prcdente

2.1 Le code de la classe Vehicule 2.2 Le code de l'interface IVehicule 2.3 Le code de la classe UnVehicule 2.4 Le code de la classe Terrestre 2.5 Le code de la classe Voiture
3. Cohrence de C# entre les notions de classe et d'interface

une classe peut implmenter plusieures interfaces les interfaces et les classes respectent les mmes rgles de polymorphisme les conflits de noms dans les interfaces
rm di Scala - 2006
page
73
Rappels essentiels sur la notion d'interface

Les interfaces ressemblent aux classes abstraites : elles contiennent des membres spcifiant certains comportements sans les implmenter. Les classes abstraites et les interfaces se diffrencient principalement par le fait qu'une classe peut implmenter un nombre quelconque d'interfaces, alors qu'une classe abstraite ne peut hriter que d'une seule classe abstraite ou non. Une interface peut servir reprsenter des comportements d'hritage multiple.
Quelques conseils gnraux prodigus par des dveloppeurs professionnels (microsoft, Borland, Sun) :
Les interfaces bien conues sont plutt petites et indpendantes les unes des autres. Un trop grand nombre de fonctions rend l'interface peu maniable. Si une modification s'avre ncessaire, une nouvelle interface doit tre cre. Si la fonctionnalit que vous crez peut tre utile de nombreux objets diffrents, faites appel une interface. Si vous crez des fonctionnalits sous la forme de petits morceaux concis, faites appel aux interfaces. L'utilisation d'interfaces permet d'envisager une conception qui spare la manire d'utiliser une classe de la manire dont elle est implmente. Deux classes peuvent partager la mme interface sans descendre ncessairement de la mme classe de base.
1. Vocabulaire et concepts en C#
Une interface C# est un contrat, elle peut contenir des proprits, des mthodes , des vnements ou des indexeurs, mais ne doit contenir aucun champ ou attribut. Une interface ne peut pas contenir des mthodes dj implmentes. Une interface ne contient que des signatures (proprits, mthodes ). Tous les membres d'une interface sont automatiquement public. Une interface est hritable. On peut construire une hirarchie d'interfaces. Pour pouvoir construire un objet partir d'une interface, il faut dfinir une classe non abstraite implmentant tous les membres de l'interface.
Les interfaces peuvent constituer des hirarchies et hriter entre elles soient l'interface IinterfA et l'interface IinterfB hritant de IinterfA . On pourra employer aussi le vocable d'tendre au sens o l'interface drive IinterfB "tend" le contrat (augmente le nombre de membres contractuels) de l'interface IinterfA . Dans tous les cas il faut une classe pour implmenter ces contrats :
page
74
code C# : interface IinterfA { event TypEvent1 OnTruc ; // vnement char Prop1 // proprit { get ; set ; } void meth1 ( ); // mthode int meth2 ( ); // mthode char meth3 ( int x ); // mthode } interface IinterfB : IinterfA { event TypEvent2 OnChose ; // vnement string Prop2 // proprit { get ; } void meth4 ( ); // mthode }
La construction d'un objet ncessite une classe implmentant l'interface La classe ClasseY doit implmenter tous les 8 membres provenant de l'hritage des interfaces : les 2 vnements OnTruc et Onchose, les 2 proprits Prop1 et Prop2, et enfin les 4 mthodes meth1, ... , meth4 . La classe ClasseY est une classe concrte (instanciable), un objet de cette classe possde en particulier tous les membres de l'interface IinterfB (et donc IinterfA car IinterfB hrite de IinterfA)
class ClasseY : ClasseX , IinterfB { // ... implmente tous les membres de InterfB } // construction et utilisation d'un objet : ClasseY Obj = new ClasseY( ) ; Obj.Prop1 = 'a' ; // proprit hrite de InterfA string s = Obj.prop2 ; // proprit hrite de InterfB Obj.meth1( ) ; // mthode hrite de InterfA etc ...
Si, ClasseY n'implmente par exemple que 7 membres sur les 8 alors C# considre que c'est une classe abstraite et vous devez la dclarer abstract :
abstract class ClasseY : ClasseX , IinterfB { // ...n' implmente que certains membres de InterfB } class ClasseZ : ClasseY { // ... implmente le reste des membres de InterfB } // ... construction d'un objet : ClasseZ Obj = new ClasseZ( ) ; Obj.Prop1 = 'a' ; // proprit hrite de InterfA Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005
)
rm di Scala - 2006
page
75
string s = Obj.prop2 ; // proprit hrite de InterfB Obj.meth1( ) ; // mthode hrite de InterfA etc ...
Les implmentations des membres d'une interface sont en gnral public Par dfaut sans dclaration explicite, les membres (indexeurs, proprits, vnements, mthodes) d'une interface ne ncessitent pas de qualificateurs de visibilit car ils sont automatiquement dclars par C# comme tant de visibilit public, contrairement une classe ou par dfaut les membres sont du niveau assembly. Ce qui signifie que toute classe qui implmente un membre de l'interface doit obligatoirement le qualifier de public sous peine d'avoir un message d'erreur du compilateur, dans cette ventualit le membre devient un membre d'instance. Comme la signature de la mthode n'est qu'un contrat, le mode de liaison du membre n'est pas fix; la classe qui implmente le membre peut alors choisir de l'implmenter soit en liaison statique, soit en liaison dynamique. Soient une interface IinterfA et une classe ClasseX hritant directement de la classe Object et implmentant cette interface, ci-dessous les deux seules implmentations possibles d'une mthode avec un rappel sur les redfinitions possibles dans des classes descendantes :
interface IinterfA { void meth1 ( ); // mthode de l'interface }
Implmentation en liaison prcoce

class ClasseX : IinterfA { public void meth1 ( ){ ... } }
Implmentation en liaison tardive

class ClasseX : IinterfA { public virtual void meth1 ( ){ ... } }
meth1 devient une mthode d'instance
Redfinitions possibles
class ClasseY : ClasseX { public new void meth1 ( ){ ... } masque statiquement celle de ClasseX } class ClasseZ : ClasseX { public new virtual void meth1 ( ){ ... } masque dynamiquement celle de ClasseX }
Redfinitions possibles
class ClasseY : ClasseX { public new void meth1 ( ){ ... } masque statiquement celle de ClasseX } class ClasseZ : ClasseX { public new virtual void meth1 ( ){ ... } masque dynamiquement celle de ClasseX } class ClasseT : ClasseX { public override void meth1 ( ){ ... } redfinit dynamiquement celle de ClasseX }
Les implmentations explicites des membres d'une interface sont spciales Une classe qui implmente une interface peut aussi implmenter de faon explicite un membre de cette interface. Lorsqu'un membre est implment de faon explicite (le nom du membre est prfix par le nom de l'interface : InterfaceXxx.NomDuMembre ), il n'est pas accessible
)
page
76
via une rfrence de classe, il est alors invisible tout objet instanci partir de la classe o il est dfini. Un membre implment de faon explicite n'est donc pas un membre d'instance. Pour utiliser un membre d'interface implment de manire explicite, il faut utiliser une rfrence sur cette interface et non une rfrence de classe; il devient visible uniquement travers une rfrence sur l'interface. Nous reprenons le mme tableau de diffrentes implmentations de la mthode void meth1 ( ) en ajoutant une nouvelle mthode void meth2 ( int x ) que nous implmentons explicitement dans les classes drives : interface IinterfA { void meth2 ( int x ); // mthode de l'interface void meth1 ( ); // mthode de l'interface } Nous implmentons l'interface IinterfA dans la classe ClasseX : 1) nous implmentons explicitement void meth2 ( int x ), 2) nous implmentons void meth1 ( ) en mthode virtuelle.
interface IinterfA { void meth2 ( int x ); // mthode de l'interface void meth1 ( ); // mthode de l'interface } class ClasseX : IinterfA { void IinterfA.meth2 ( int x ){ ... } public virtual void meth1 ( ){ ... } } Comprenons bien que la classe ClasseX ne possde pas cet instant une mthode d'instance qui se nommerait meth2, par exemple si dans la mthode virtuelle meth1 nous utilisons le paramtre implicite this qui est une rfrence la future instance, l'audit de code de C#Builder nous renvoie 7 mthodes comme visibles (6 provenant de la classe mre Object et une seule provenant de ClasseX), la mthode IinterfA.meth2 n'est pas visible :
rm di Scala - 2006
page
77
Lorsque l'on instancie effectivement un objet de classe ClasseX, cet objet ne voit comme mthode provenant de ClasseX que la mthode meth1 :
La mthode meth2 implmente explicitement en IinterfA.meth2 devient visible uniquement si l'on utilise une rfrence sur l'interface IinterfA, l'exemple ci-dessous montre qu'alors les deux mthodes meth1 et meth2 sont visibles :
L'audit de code de Visual C# fournit plus de prcision directement :
page
78
Nous voyons bien que la mthode est qualifie avec sa signature dans IinterfA, voyons dans l'exemple ci-dessous que nous pouvons dclarer une mthode d'instance ayant la mme signature que la mthode explicite, voir mme de surcharger cette mthode d'instance sans que le compilateur C# n'y voit de conflit car la mthode explicite n'est pas rang dans la table des mthodes d'instances de la classe : class ClasseX : IinterfA { void IinterfA.meth2 ( int x ){ ... } //mthode de IinterfA implmente explicitement public virtual void meth2 ( int x ){ ... } //mthode de la ClasseX surcharge public virtual void meth2 ( char c ){ ... } //mthode de la ClasseX surcharge public virtual void meth1 ( ){ ... } //mthode de IinterfA implmente virtuellement }
rm di Scala - 2006
La rfrence Obj1 peut appeller les deux surcharges de la mthode d'instance meth2 de la classe ClasseX :
)
page
79
La rfrence Obj2 sur IinterfA fonctionne comme nous l'avons montr plus haut, elle ne peut voir de la mthode meth2 que son implmentation explicite :
Cette fonctionnalit d'implmentation explicite spcifique C# peut tre utilise dans au moins deux cas utiles au dveloppeur : Lorsque vous voulez qu'un membre (une mthode par exemple) implment d'une interface soit priv dans une classe pour toutes les instances de classes qui en driveront, l'implmentation explicite vous permet de rendre ce membre (cette mthode) inaccessible tout objet. Lors d'un conflit de noms si deux interfaces possdent un membre ayant la mme signature et que votre classe implmente les deux interfaces.
1.1 Spcification d'un exemple complet Utilisons la notion d'interface pour fournir un polymorphisme une hirarchie de classe de vhicules fonde sur une interface. : Soit au dpart une classe abstraite Vehicule et une interface IVehicule.
1.1.A) Une classe abstraite La classe abstraite Vehicule contient trois mthodes :
page
80
La mthode Dmarrer qui est abstraite. La mthode RpartirPassagers de rpartition des passagers bord du vhicule, implante avec un corps vide. La mthode PriodicitMaintenance renvoyant la priodicit de la maintenance obligatoire du vhicule, implante avec un corps vide.
1.1.B) Une interface Afin d'utiliser les possibilits de C#, l'interface IVehicule propose un contrat d'implmentation pour un vnement, un indexeur, une proprit et une mthode :
L'vnement OnStart est de type dlgu (on construit un type dlgu Starting( ) spcifique pour lui) et se dclenchera au dmarrage du futur vhicule, L'indexeur this [int ] est de type string et permettra d'accder une liste indice d'informations sur le futur vhicule, La proprit TypeEngin est en lecture et criture et concerne le type du futur vhicule dans la marque, La mthode Stopper( ) indique comment le futur vhicule s'immobilisera.
1.1.C) Une simulation d'hritage multiple Nous souhaitons construire une classe abstraite UnVehicule qui "hrite" la fois des fonctionnalits de la classe Vehicule et de celles de l'interface IVehicule. Il nous suffit en C# de faire hriter la classe UnVehicule de la classe Vehicule , puis que la classe UnVehicule implmente les propositions de contrat de l'interface IVehicule :
rm di Scala - 2006
page
81
1.1.D) Encore une classe abstraite, mais plus "concrte" Nous voulons maintenant proposer une spcialisation du vhicule en crant une classe abstraite Terrestre , base des futurs vhicules terrestres. Cette calsse implantera de faon explicite la mthode RpartirPassagers de rpartition des passagers et la mthode PriodicitMaintenance renvoyant la priodicit de la maintenance. Cette classe Terrestre reste abstraite car elle ne fournit pas l'implmentation de la mthode Demarrer :
1.1.E) Une classe concrte Nous finissons notre hirarchie par une classe Voiture qui descend de la classe Terrestre , qui implante la mthode Demarrer( ) et qui redfinie la mthode Stopper( ) :
page
82
Ce qui nous donne le schma d'hritage total suivant :
1.2 Implantation en C# de l'exemple Nous proposons ci-dessous pour chaque classe ou interface une implmenation en C#. 1.2.A) La classe abstraite Vehicule
rm di Scala - 2006
page
83
abstract class Vehicule // classe abstraite mre { public abstract void Demarrer ( ); // mthode abstraite public void RpartirPassagers ( ) { } // implantation de mthode avec corps vide public void PriodicitMaintenance ( ) { } // implantation de mthode avec corps vide }
1.2.B) L'interface IVehicule
public delegate void Starting ( );
// declaration de type dlgu
interface IVehicule { event Starting OnStart ; // dclaration d'vnement du type dlgu : Starting string this [ int index] // dclaration d'indexeur { get ; set ; } string TypeEngin // dclaration de proprit { get ; set ; } void Stopper ( ); // dclaration de mthode }
page
84
1.2.C) La classe UnVehicule
abstract class UnVehicule : Vehicule , IVehicule // hrite de la classe mre et implmente l'interface { private string nom = ""; private string [ ] ArrayInfos = new string [10] ; public event Starting OnStart ; protected void LancerEvent () { if( OnStart != null) OnStart (); } public string this [ int index] // implantation Indexeur { get { return ArrayInfos[index] ; } set { ArrayInfos[index] = value ; } } public string TypeEngin // implantation proprit { get { return nom ; } set { nom = value ; } } public virtual void Stopper ( ) { } // implantation de mthode avec corps vide }
rm di Scala - 2006
page
85
1.2.D) La classe Terrestre
abstract class Terrestre : UnVehicule { public new void RpartirPassagers ( ) { //...implantation de mthode } public new void PriodicitMaintenance ( ) { //...implantation de mthode } }
1.2.E) La classe Voiture
class Voiture : Terrestre { public override void Demarrer ( ) { LancerEvent ( ); } public override void Stopper ( ) { //... } }
page
86
2. Analyse du code de liaison de la solution prcdente
Nous nous interessons au mode de liaison des membres du genre : mthodes, proprits, indexeurs et vnements. Rappelons au lecteur que la liaison statique indique que le compilateur lie le code lors de la compilation, alors que dans le cas d'une liaison dynamique le code n'est choisi et li que lors de l'excution. 2.1 Le code de la classe Vehicule
abstract class Vehicule { public abstract void Demarrer ( ); // mthode abstraite public void RpartirPassagers ( ) { } // implantation de mthode avec corps vide public void PriodicitMaintenance ( ) { } // implantation de mthode avec corps vide }
Analyse : Sans qualification particulire une mthode est liaison statique : La mthode public void RpartirPassagers ( ) est donc laison statique. La mthode public void PriodicitMaintenance ( ) est donc laison statique. Une mthode qualifie abstract est implicitement virtuelle : La mthode public abstract void Demarrer ( ) est donc laison dynamique.
2.2 Le code de l'interface IVehicule
interface IVehicule { event Starting OnStart ; // dclaration d'vnement du type dlgu : Starting string this [ int index] // dclaration d'indexeur { get ; set ; } string TypeEngin // dclaration de proprit { get ; set ; } void Stopper ( ); // dclaration de mthode }
rm di Scala - 2006
page
87
Analyse : Une interface n'est qu'un contrat, les membres dclars comme signatures dans l'interface n'tant pas implmentes, la question de leur liaison ne se pose pas au niveau de l'interface, mais lors de l'implmentation dans une classe ultrieure : La mthode void Stopper ( ); pourra donc tre plus tard soit statique, soit dynamique. L'vnement event Starting OnStart ; pourra donc tre plus tard soit statique, soit dynamique. La proprit string TypeEngin , pourra donc tre plus tard soit statique, soit dynamique. L'indexeur string this [ int index] , pourra donc tre plus tard soit statique, soit dynamique.
2.3 Le code de la classe UnVehicule
abstract class UnVehicule : Vehicule , IVehicule { private string nom = ""; private string [ ] ArrayInfos = new string [10] ; public event Starting OnStart ; protected void LancerEvent ( ) { if( OnStart != null) OnStart (); } public string this [ int index] // implantation Indexeur { get { return ArrayInfos[index] ; } set { ArrayInfos[index] = value ; } } public string TypeEngin // implantation proprit { get { return nom ; } set { nom = value ; } } public virtual void Stopper ( ) { } // implantation de mthode avec corps vide }
Analyse : Le qualificateur virtual indique que l'lment qualifi est virtuel, donc liaison dynamique; sans autre qualification un lment est par dfaut liaison statique : La mthode public virtual void Stopper ( ) est liaison dynamique. L'vnement public event Starting OnStart est liaison statique. La proprit public string TypeEngin est liaison statique.
)
page
88
L'indexeur public string this [ int index] est liaison statique. La mthode protected void LancerEvent ( ) est liaison statique.
2.4 Le code de la classe Terrestre
abstract class Terrestre : UnVehicule { public new void RpartirPassagers ( ) { //...implantation de mthode } public new void PriodicitMaintenance ( ) { //...implantation de mthode } }
Analyse : Dans la classe mre Vehicule les deux mthodes RpartirPassagers et PriodicitMaintenance sont liaison statique, dans la classe Terrestre : La mthode public new void RpartirPassagers ( ) est laison statique et masque la mthode mre. La mthode public new void PriodicitMaintenance ( ) est laison statique et masque la mthode mre.
2.5 Le code de la classe Voiture
class Voiture : Terrestre { public override void Demarrer ( ) { LancerEvent ( ); } public override void Stopper ( ) { //... } }
rm di Scala - 2006
page
89
Analyse : La mthode Demarrer( ) est hrite de la classe mre Vehicule, la mthode Stopper( ) est hrite de la classe UnVehicule : La mthode public override void Demarrer ( ) est laison dynamique et redfinit la mthode abstraite mre. La mthode public override void Stopper ( ) est laison dynamique et redfinit la mthode virtuelle corps vide de la classe UnVehicule.
3. Cohrence entre les notions de classe et d'interface dans C#
Une classe peut implmenter plusieurs interfaces. Dans ce cas nous avons une excellente alternative l'hritage multiple. Lorsque l'on cre une interface, on fournit un ensemble de dfinitions et de comportements qui ne devraient plus tre modifis. Cette attitude de constance dans les dfinitions, protge les applications crites pour utiliser cette interface. Les variables de types interface respectent les mmes rgles de transtypage que les variables de types classe. Les objets de type classe clA peuvent tre transtyps et refrencs par des variables d'interface IntfA dans la mesure o la classe clA implmente linterface IntfA. (cf. polymorphisme d'objet)
Une classe peut implmenter plusieures interfaces Soit la dfinition suivante o la classe UnVehiculeMoteur hrite de la classe abstraite Vehicule et implmente l'interface IVehicule de l'exemple prcdent, et supposons qu'en plus cette classe implmente l'interface IMoteur. L'interface IMoteur explique que lorsqu'un vhicule est moteur, il faut se proccuper de son type de carburant et de sa consommation :
page
90
Ci-dessous le code C# correspondant cette dfinition, plus une classe concrte Voiture instanciable drivant de la classe abstraite UnVehiculeMoteur :
abstract class Vehicule { public abstract void Demarrer ( ); // mthode abstraite public void RpartirPassagers ( ) { } // implantation de mthode avec corps vide public void PriodicitMaintenance ( ) { } // implantation de mthode avec corps vide } interface IVehicule { event Starting OnStart ; // dclaration d'vnement du type dlgu : Starting string this [ int index] // dclaration d'indexeur { get ; set ; } string TypeEngin // dclaration de proprit { get ; set ; } void Stopper ( ); // dclaration de mthode } enum Energie { gaz , fuel , ess } // type numr pour le carburant interface IMoteur { Energie carburant // dclaration de proprit { get ; } int consommation ( ); // dclaration de mthode }
rm di Scala - 2006
page
91
abstract class UnVehiculeMoteur : Vehicule , IVehicule , IMoteur { private string nom = ""; private Energie typeEnerg = Energie.fuel ; private string [ ] ArrayInfos = new string [10] ; public event Starting OnStart ; protected void LancerEvent ( ) { if( OnStart != null) OnStart ( ); } public string this [ int index] // implantation Indexeur de IVehicule { get { return ArrayInfos[index] ; } set { ArrayInfos[index] = value ; } } public string TypeEngin // implantation proprit de IVehicule { get { return nom ; } set { nom = value ; } } public Energie carburant // implantation proprit de IMoteur { get { return typeEnerg ; } } public virtual void Stopper ( ) { } // implantation vide de mthode de IVehicule public virtual int consommation ( ) { return .... } // implantation de mthode de IMoteur } class Voiture : UnVehiculeMoteur { public override void Demarrer ( ) { LancerEvent ( ); } public override void Stopper ( ) { //...implantation de mthode } public new void RpartirPassagers ( ) { //...implantation de mthode } public new void PriodicitMaintenance ( ) { //...implantation de mthode } }
Les interfaces et classes respectent les mmes rgles de polymorphisme Il est tout fait possible d'utiliser des variables de rfrence sur des interfaces et de les transtyper d'une manire identique des variables de rfrence de classe. En particulier le polymorphisme de rfrence s'applique aux rfrences d'interfaces.
page
92
Le polymorphisme de rfrence sur les classes de l'exemple prcdent abstract class Vehicule { ... } interface IVehicule { ... } enum Energie { gaz , fuel , ess } interface IMoteur { ... } abstract class UnVehiculeMoteur : Vehicule , IVehicule , IMoteur { ... } class Voiture : UnVehiculeMoteur { ... } class UseVoiture1 { public string use ( IVehicule x ){ return x.TypeEngin ; } } class UseVoiture2 { public string use ( UnVehiculeMoteur x ){ return x.TypeEngin ; } } class UseVoiture3 { public string use ( Voiture x ){ return x.TypeEngin ; } } class MaClass { static void Main(string [ ] args) { const string ch; s = "le client utilise une "; string ch ; IVehicule a1; UnVehiculeMoteur b1; Voiture c1; a1 = new Voiture( ); a1.TypeEngin = "Renault"; b1= new Voiture( ); b1.TypeEngin = "Citron"; c1 = new Voiture( ); c1.TypeEngin = "Peugeot"; UseVoiture1 client = new UseVoiture1( ); ch = s+client.use(a1); System.Console.WriteLine(ch); ch = s+client.use(b1); System.Console.WriteLine(ch); ch = s+client.use(c1); System.Console.WriteLine(ch); } }
code d'excution avec 3 objets diffrents static void Main(string [ ] args) { .... idem UseVoiture1 client = new UseVoiture1( ); ch = s+client.use(a1); System.Console.WriteLine(ch); ch = s+client.use(b1); System.Console.WriteLine(ch); ch = s+client.use(c1); System.Console.WriteLine(ch); } IVehicule |__UnVehiculeMoteur |__Voiture Aprs excution :
a1 est une rfrence sur IVehicule, b1 est une rfrence sur une interface fille de IVehicule, c1 est de classe Voiture implmentant IVehicule. Donc chacun de ces trois genres de paramtre peut tre pass par polymorphisme de rfrence d'objet la mthode public string use ( IVehicule x )
rm di Scala - 2006
page
93
static void Main(string [ ] args) { .... idem UseVoiture2 client = new UseVoiture2( ); ch = s+client.use((UnVehiculeMoteur)a1); System.Console.WriteLine(ch); ch = s+client.use(b1); System.Console.WriteLine(ch); ch = s+client.use(c1); System.Console.WriteLine(ch); } IVehicule |__UnVehiculeMoteur |__Voiture
Aprs excution :
Le polymorphisme de rfrence d'objet appliqu la mthode public string use ( UnVehiculeMoteur x ) indique que les paramtres passs doivent tre de type UnVehiculeMoteur ou de type descendant. La variable a1 est une rfrence sur IVehicule qui ne descend pas de UnVehiculeMoteur, il faut donc transtyper la rfrence a1 soit : (UnVehiculeMoteur)a1. Aprs excution :
static void Main(string [ ] args) { .... idem UseVoiture3 client = new UseVoiture3( ); ch = s+client.use( (Voiture)a1 ); System.Console.WriteLine(ch); ch = s+client.use( (Voiture)b1 ); System.Console.WriteLine(ch); ch = s+client.use(c1); System.Console.WriteLine(ch); } IVehicule |__UnVehiculeMoteur |__Voiture
Le polymorphisme de rfrence d'objet appliqu la mthode public string use ( Voiture x ) indique que les paramtres pass doivent tre de type Voiture ou de type descendant. La variable a1 est une rfrence sur IVehicule qui ne descend pas de Voiture, il faut donc transtyper la rfrence a1 soit : (Voiture)a1 La variable b1 est une rfrence sur UnVehiculeMoteur qui ne descend pas de Voiture, il faut donc transtyper la rfrence b1 soit : (Voiture)b1
Les oprateurs is et as sont utilisables avec des rfrences d'interfaces en C#. Reprenons l'exemple prcdent :
abstract class Vehicule { ... } interface IVehicule { ... } enum Energie { gaz , fuel , ess } interface IMoteur { ... } abstract class UnVehiculeMoteur : Vehicule , IVehicule , IMoteur { ... } class Voiture : UnVehiculeMoteur { ... } class UseVoiture1 { public string use ( IVehicule x ){ if (x is UnVehiculeMoteur) { int consom = (x as UnVehiculeMoteur).consommation( ); return " consommation="+consom.ToString( ) ; } else return x.TypeEngin ; } }
page
94
Les conflits de noms dans les interfaces Il est possible que deux interfaces diffrentes possdent des membres ayant la mme signature. Une classe qui implmente ces deux interfaces se trouvera confronte un conflit de nom (ambigut). Le compilateur C# exige ds lors que l'ambigut soit leve avec le prfixage du nom du membre par celui de l'interface correspondante (implmentation explicite). L'exemple ci-dessous est figur avec deux interfaces IntA et IntB contenant chacune deux mthodes portant les mmes noms et plus particulirement la mthode meth1 possde la mme signature dans chaque interface. Soit ClasseUn une classe implmentant ces deux interfaces. Voici comment fait C# pour choisir les appels de mthodes implantes. Le code source de ClasseUn implmentant les deux interfaces IntA et IntB :
interface IntA{ void meth1( int x ); void meth2( ); } interface IntB{ void meth1( int x ); void meth2( int y ); } class ClasseUn : IntA , IntB { public virtual void meth1( int x ){ } void IntA.meth1( int x ){ } void IntB.meth1( int x ){ } public virtual void meth2( ){ } public void meth2( int y ){ } }
Schma expliquant ce que C# analyse dans le code source prcdent :
Lorsque l'on instancie effectivement 3 objets de classe ClasseUn prcdente, et que l'on dclare chaque objet avec un type de rfrence diffrent : classe ou interface, le schma cidessous indique quels sont les diffrents appels de mthodes corrects possibles :
rm di Scala - 2006
page
95
Il est aussi possible de transtyper une rfrence d'objet de classe ClasseUn en une rfrence d'interface dont elle hrite (les appels sont identiques ceux du schma prcdent) : class Tests { void methTest( ) { ClasseUn Obj1 = new ClasseUn( ); IntA Obj2 = ( IntA )Obj1; IntB Obj3 = ( IntB )Obj1; Obj1.meth2( ); Obj1.meth2(74); Obj2.meth2( ); Obj3.meth2(100); Obj1.meth1(50); Obj2.meth1(40); Obj3.meth1(40); } } Nous remarquons qu'aucun conflit et aucune ambigut de mthode ne sont possibles et que grce l'implmentation explicite, toutes les mthodes de mme nom sont accessibles. Enfin, nous avons prfr utiliser le transtypage dtaill dans : IntA Obj2 = ( IntA )Obj1 ; Obj2.meth1(40) ;
plutt que l'criture quivalente : (( IntA )Obj1).meth1(40) ; //...appel de IntA.meth1(int x)

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005 page
96
Car l'oubli du parenthsage externe dans l'instruction " (( IntA )Obj1).meth1(40) " peut provoquer des incomprhensions dans la mesure o aucune erreur n'est signal par le compilateur car ce n'est plus la mme mthode qui est appele. ( IntA )Obj1.meth1(40) ; //...appel de public virtual ClasseUn.meth1(int x)
rm di Scala - 2006
page
97
Classe de dlgation
Plan gnral:
Les classes de dlgations

1.1 Dfinition classe de dlgation - dlgu 1.2 Dlgu et mthodes de classe - dfinition 1.3 Dlgu et mthodes de classe - informations pendant l'excution 1.4 Dlgu et mthodes d'instance - dfinition 1.5 Plusieurs mthodes pour le mme dlgu 1.6 Excution des mthodes d'un dlgu multicast - Exemple de code
page
98
Il existe en Delphi la notion de pointeur de mthode utilise pour implanter la notion de gestionnaire dvnements. C# a repris cette ide en l'encapsulant dans un concept objet plus abstrait : la notion de classes de dlgations. Dans la machine virtuelle CLR, la gestion des vnements est fonde sur les classes de dlgations, il est donc essentiel de comprendre le modle du dlgu pour comprendre le fonctionnement des vnements en C#.
1.Les classes de dlgations

Note de microsoft l'attention des dveloppeurs :
La classe Delegate est la classe de base pour les types dlgus. Toutefois, seuls le systme et les compilateurs peuvent driver de manire explicite de la classe Delegate ou MulticastDelegate. En outre, il n'est pas possible de driver un nouveau type d'un type dlgu. La classe Delegate n'est pas considre comme un type dlgu. Il s'agit d'une classe utilise pour driver des types dlgus.
1.1 Dfinition classe de dlgation - dlgu Le langage C# contient un mot cl delegate , permettant au compilateur de construire une classe drive de la classe MulticastDelegate drive elle-mme de la classe Delegate. Nous ne pouvons pas instancier une objet de classe Delegate, car le constructeur est spcifi protected et n'est donc pas accessible :
C'est en fait via ce mot cl delegate que nous allons construire des classes qui ont pour nom : classes de dlgations. Ces classes sont des classes du genre rfrence, elles sont instanciables et un objet de classe dlgation est appel un dlgu.
Un objet de classe dlgation permet de rfrencer (pointer vers) une ou plusieurs mthodes. Il s'agit donc de l'extension de la notion de pointeur de mthode de Delphi. Selon les auteurs une classe de dlgation peut tre ausi nomme classe dlgue, type dlgu voir mme tout simplement dlgu. Il est essentiel dans le texte lu de bien distinguer la classe et l'objet instanci.
rm di Scala - 2006
page
99
Lorsque nous utiliserons le vocable classe dlgu ou type dlgu nous parlerons de la classe de dlgation dun objet dlgu. Il est donc possible de crer un nouveau type de dlgu (une nouvelle classe) dans un programme, ceci d'une seule manire : en utilisant le qualificateur delegate. Ci-dessous nous dclarons un type dlgu (une nouvelle classe particulire) nomm NomTypeDelegue : delegate string NomTypeDelegue ( int parametre) ; Un objet dlgu peut donc tre instanc partir de cette "classe" comme n'importe quel autre objet : NomTypeDelegue Obj = new NomTypeDelegue ( <paramtre> ) Il ne doit y avoir qu'un seul paramtre <paramtre> et c'est obligatoirement un nom de mthode. Soit MethodeXYZ le nom de la mthode pass en paramtre, nous dirons alors que le dlgu (l'objet dlgu) rfrence la mthode MethodeXYZ .
Les mthodes rfrences par un dlgu peuvent tre : des mthodes de classe ( static ) ou des mthodes d'instance Toutes les mthodes rfrences par un mme dlgu ont la mme signature partielle : mme type de retour du rsultat, mme nombre de paramtres, mme ordre et type des paramtres, seul leur nom diffre.
page
100
1.2 Dlgu et mthodes de classe - dfinition
Un type commenant par le mot clef delegate est une classe dlgation. ci-dessous la syntaxe de 2 exemples de dclaration de classe dlgation : delegate string Deleguer1( int x ) ; delegate void Deleguer2( string s ) ; Un objet instanci partir de la classe Deleguer1 est appel un dlgu de classe Deleguer1 : Deleguer1 FoncDeleg1 = new Deleguer1 ( Fonc1 ) ; o Fonc1 est une mthode : static string Fonc1 ( int x ) { ... } Un objet instanci partir de la classe Deleguer2 est appel un dlgu de classe Deleguer2 : Deleguer2 FoncDeleg2 = new Deleguer2 ( Fonc2 ) ; o Fonc2 est une autre mthode : static void Fonc2 ( string x ) { ... }
Nous avons cr deux types dlgations nomms Deleguer1 et Deleguer2 : Le type Deleguer1 permet de rfrencer des mthodes ayant un paramtre de type int et renvoyant un string. Le type Deleguer2 permet de rfrencer des mthodes ayant un paramtre de type string et ne renvoyant rien. Les fonctions de classe Fonc1 et Fonc11 rpondent la signature partielle du type Deleguer1 static string Fonc1 ( int x ) { ... } static string Fonc11 ( int x ) { ... } On peut crer un objet (un dlgu) qui va rfrencer l'une ou l'autre de ces deux fonctions : Deleguer1 FoncDeleg1 = new Deleguer1 ( Fonc1 ) ; ou bien Deleguer1 FoncDeleg1 = new Deleguer1 ( Fonc11 ) ; On peut maintenant appeler le dlgu FoncDeleg1 dans une instruction avec un paramtre d'entre de type int, selon que le dlgu rfrence Fonc1 ou bien Fonc11 c'est l'une ou l'autre des ces fonctions qui est en fait appele.
Source d'un exemple C# et excution :

delegate string Deleguer1 ( int x ); class ClasseA { static string Fonc1 ( int x ) { return ( x * 10 ) .ToString ( ); } static string Fonc11 ( int x ) { return ( x * 100 ) .ToString ( ); } static void Main ( string [] args ) { string s = Fonc1 ( 32 ); System .Console.WriteLine ("Fonc1(32) = " + s ); s = Fonc11 ( 32 ); // appel de fonction classique System .Console.WriteLine ("Fonc11(32) = " + s ); Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005
)
rm di Scala - 2006
page
101
System .Console.WriteLine ("\nLe dlgu rfrence Fonc1 :"); Deleguer1 FoncDeleg1 = new Deleguer1 ( Fonc1 ) ; s = FoncDeleg1 ( 32 ); // appel au dlgu qui appelle la fonction System .Console.WriteLine ("FoncDeleg1(32) = " + s ); System .Console.WriteLine ("\nLe dlgu rfrence maintenant Fonc11 :"); FoncDeleg1 = new Deleguer1 ( Fonc11 ) ; // on change d'objet rfrenc (de fonction) s = FoncDeleg1 ( 32 ); // appel au dlgu qui appelle la fonction System .Console.WriteLine ("FoncDeleg1(32) = " + s ); System .Console.ReadLine ( ); } }
Rsultats d'excution sur la console :
1.3 Dlgu et mthodes de classe - informations pendant l'excution Comme une rfrence de dlgu peut pointer (rfrencer) vers des mthodes de classes diffrentes au cours de l'excution, il est intressant d'obtenir des informations sur la mthode de classe actuellement rfrence par le dlgu. Nous donnons ci-dessous les deux proprits publiques qui sont utiles lors de cette recherche d'informations, elles proviennent de la classe mre Delegate non hritable par programme :
page
102
La proprit Target sert plus particulirement lorsque le dlgu rfrence une mthode d'instance, la proprit Method est la seule utilisable lorsque la mthode rfrence par le dlgu est une mthode de classe (mthode marque static). Lorsque la mthode rfrence par le dlgu est une mthode de classe le champ Target a la valeur null. Ci-dessous nous avons extrait quelques informations concernant la proprit Method qui est elle-mme de classe MethodInfo :
Ces proprits sont des membres de la proprit Method qui est applicable uniquement lorsque le dlgu en cours rfrence une mthode de classe (qualifie static).
Nous illustrons dans la figure ci-aprs, dans le cas d'une mthode de classe, l'utilisation des proprits Name, DeclaringType et ReturnType membres de la proprit Method :
rm di Scala - 2006
page
103
Nous obtenons ainsi des informations sur le nom, le type du rsultat et la classe de la mthode static pointe par le dlgu.
Source complet excutable d'un exemple d'information sur la mthode de classe rfrence :
namespace PrDelegate { delegate string Deleguer1 ( int x ); class ClasseA { static string Fonc1 ( int x ) { return ( x * 10 ) .ToString ( ); } static void Main ( string [ ] args ) { System .Console.WriteLine ("\nLe dlgu rfrence Fonc1 :"); Deleguer1 FoncDeleg1 = new Deleguer1 ( Fonc1 ) ; System .Console.WriteLine ( "nom : "+FoncDeleg1.Method.Name ); System .Console.WriteLine ("classe : "+ FoncDeleg1.Method.DeclaringType.ToString( ) ); System .Console.WriteLine ( "retour : "+FoncDeleg1.Method.ReturnType.ToString( ) ); System .Console.ReadLine ( ); } } }
page
104
1.4 Dlgu et mthodes d'instance - dfinition

Outre une mthode de classe, un dlgu peut pointer aussi vers une mthode d'instance(une mthode d'un objet). Le fonctionnement (dclaration, instanciation, utilisation) est identique celui du rfrencement d'une mthode de classe, avec syntaxiquement l'obligation, lors de l'instanciation du dlgu, d'indiquer le nom de l'objet ainsi que le nom de la mthode Obj.Methode (similitude avec le pointeur de mthode en Delphi). Ci-dessous la syntaxe d'un exemple de dclaration de classe dlgation pour une mthode d'instance, nous devons : 1) Dclarer ne classe contenant une mthode public class clA { public int meth1(char x) { .... } } 2) Dclarer un type dlgation delegate int Deleguer( char x ) ; 3) Instancier un objet de la classe clA clA ObjA = new clA ( ) ; 4) Instancier partir de la classe Deleguer un dlgu Deleguer FoncDeleg = new Deleguer ( ObjA.meth1 ) ;
Nous illustrons dans la figure ci-aprs, dans le cas d'une mthode d'instance, l'utilisation de membres de la proprit Method et de la proprit Target :
rm di Scala - 2006
page
105
Source complet excutable d'un exemple d'information sur la mthode d'instance rfrence :
namespace PrDelegate { delegate int Deleguer ( char x ); class ClasseA { public int meth1 ( char x ) { return x ; } static void Main ( string [ ] args ) { ClasseA ObjX , ObjA = new ClasseA( ); System .Console.WriteLine ("Un dlgu rfrence ObjA.meth1 :"); Deleguer FoncDeleg = new Deleguer ( ObjA.meth1 ) ; ObjX = (ClasseA)FoncDeleg.Target; if (ObjX.Equals(ObjA)) System.Console.WriteLine ("Target rfrence bien ObjA"); else System.Console.WriteLine ("Target ne rfrence pas ObjA"); System.Console.WriteLine ( "\nnom : "+FoncDeleg.Method.Name ); System.Console.WriteLine ("classe : "+ FoncDeleg.Method.DeclaringType.ToString( ) ); System.Console.WriteLine ( "retour : "+FoncDeleg.Method.ReturnType.ToString( ) ); System.Console.ReadLine ( ); } } }
page
106
Dans le programme prcdent, les lignes de code suivantes : ObjX = (ClasseA)FoncDeleg.Target ; if (ObjX.Equals(ObjA)) System.Console.WriteLine ("Target rfrence bien ObjA") ; else System.Console.WriteLine ("Target ne rfrence pas ObjA") ; servent faire "pointer" la rfrence ObjX vers l'objet vers lequel pointe FoncDeleg.Target. La rfrence de cet objet est transtype car ObjX est de type ClasseA, FoncDeleg.Target est de type Object et le compilateur n'accepterait pas l'affectation ObjX = FoncDeleg.Target. Le test if (ObjX.Equals(ObjA))... permet de nous assurer que les deux rfrences ObjX et ObjA pointent bien vers le mme objet.
1.5 Plusieurs mthodes pour le mme dlgu C# autorise le rfrencement de plusieurs mthodes par le mme dlgu, nous utiliserons le vocabulaire de dlgu multicast pour bien prciser qu'il rfrence plusieurs mthodes. Le dlgu multicast conserve les rfrencements dans une liste d'objet. Les mthodes ainsi rfrences peuvent chacune tre du genre mthode de classe ou mthode d'instance, elles doivent avoir la mme signature. Rappelons qu'un type dlgu multicast est une classe qui hrite intrinsquement de la classe MulticasteDelegate :
La documentation de .Net Framework indique que la classe MulticasteDelegate contient en particulier trois champs privs : Object _target ; Int32 _methodPtr ;
)
rm di Scala - 2006
page
107
MulticasteDelegate _prev ; Le champ _prev est utilis pour maintenir une liste de MulticasteDelegate Lorsque nous dclarons un programme comme celui-ci :
delegate int Deleguer ( char x ); class ClasseA { public int meth100 ( char x ) { System.Console.WriteLine ("Excution de meth100('"+x+"')"); return x+100 ; } static void Main ( string [] args ) { ClasseA ObjA = new ClasseA( ); Deleguer FoncDeleg = new Deleguer ( ObjA.meth100 ) ; } }
Lors de l'excution, nous avons vu qu'il y a cration d'un ObjA de ClasseA et cration d'un objet dlgu FoncDeleg, les proprits Method et Target sont automatiquement initialises par le compilateur :
En fait, ce sont les champs privs qui sont initialiss et les proprits Method et Target qui sont en lecture seulement, lisent les contenus respectifs de _methodPtr et de _target; le champ _prev est pour l'instant mis null , enfin la mthode meth100(...) est actuellement en tte de liste.
page
108
Figure virtuelle de l'objet dlgu ce stade :
Il est possible d'ajouter une nouvelle mthode meth101(...) au dlgu qui va la mettre en tte de liste la place de la mthode meth100(...) qui devient le deuxime lment de la liste. C# utilise l'oprateur d'addition pour implmenter l'ajout d'une nouvelle mthode au dlgu. Nous tendons le programme prcdent :
delegate int Deleguer ( char x ); class ClasseA { public int meth100 ( char x ) { System.Console.WriteLine ("Excution de meth100('"+x+"')"); return x+100 ; } public int meth101 ( char x ) { System.Console.WriteLine ("Excution de meth101('"+x+"')"); return x+101 ; } static void Main ( string [] args ) { ClasseA ObjA = new ClasseA( ); //-- meth100 est en tte de liste : Deleguer FoncDeleg = new Deleguer ( ObjA.meth100 ) ; // meth101 est ajoute en tte de liste devant meth100 : FoncDeleg = FoncDeleg + new Deleguer ( ObjA.meth101 ) ; } }
Figure virtuelle de l'objet dlgu cet autre stade :
rm di Scala - 2006
page
109
C# permet de consulter et d'utiliser si nous le souhaitons toutes les rfrencement de mthodes en nous renvoyant la liste dans une tableau de rfrence de type Delegate grce la mthode GetInvocationList. Le source ci-dessous retourne dans le tableau Liste, la liste d'appel dans l'ordre d'appel, du dlgu FoncDeleg : Delegate[ ] Liste = FoncDeleg.GetInvocationList( ) ;
1.6 Excution des mthodes d'un dlgu multicast - Exemple de code Lorsque l'on invoque le dlgu sur un paramtre effectif, C# appelle et excute squentiellement les mthodes contenues dans la liste jusqu' puisement. L'ordre d'appel est celui du stockage : la premire stocke est excute en premier, la suivante aprs, la dernire mthode ajoute est excute en dernier, s'il y a un rsultat de retour, c'est celui de la dernire mthode ajoute qui est renvoy , les autres rsultats de retour sont ignors. L'exemple ci-dessous reprend les notions que nous venons d'exposer. Source complet excutable d'un exemple de dlgu multicast :
namespace PrDelegate { delegate int Deleguer ( char x ); class ClasseA { public int champ; public int meth100 ( char x ) { System.Console.WriteLine ("Excution de meth100('"+x+"')"); return x+100 ; } public int meth101 ( char x ) { System.Console.WriteLine ("Excution de meth101('"+x+"')"); return x+101 ; } public int meth102 ( char x ) { Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005
)
page
110
System.Console.WriteLine ("Excution de meth102('"+x+"')"); return x+102 ; } public static int meth103 ( char x ) { System.Console.WriteLine ("Excution de meth103('"+x+"')"); return x+103 ; } static void Main ( string [] args ) { System.Console.WriteLine ("Un dlgu rfrence ObjA.meth1 :" ) ; ClasseA ObjX , ObjA = new ClasseA( ); //-- instanciation du dlgu avec ajout de 4 mthodes : Deleguer FoncDeleg = new Deleguer ( ObjA.meth100 ) ; FoncDeleg += new Deleguer ( ObjA.meth101 ) ; FoncDeleg += new Deleguer ( ObjA.meth102 ) ; FoncDeleg += new Deleguer ( meth103 ) ; //--la mthode meth103 est en tte de liste : ObjX = (ClasseA)FoncDeleg.Target ; if (ObjX == null) System.Console.WriteLine ("Mthode static, Target = null") ; else if (ObjX.Equals(ObjA))System .Console.WriteLine ("Target rfrence bien ObjA") ; else System.Console.WriteLine ("Target ne rfrence pas ObjA") ; System.Console.WriteLine ( "\nnom : "+FoncDeleg.Method.Name ); System.Console.WriteLine ( "classe : "+FoncDeleg.Method.DeclaringType.ToString( ) ) ; System.Console.WriteLine ( "retour : "+FoncDeleg.Method.ReturnType.ToString( ) ); //--Appel du dlgu sur le paramtre effectif 'a' : ObjA.champ = FoncDeleg('a') ; //code ascii 'a' = 97 System.Console.WriteLine ( "\nvaleur du champ : "+ObjA.champ) ; System.Console.WriteLine ( "----------------------------------") ; //-- Parcours manuel de la liste des mthodes rfrences : Delegate[ ] Liste = FoncDeleg.GetInvocationList( ) ; foreach ( Delegate Elt in Liste ) { ObjX = (ClasseA)Elt.Target ; if (ObjX == null) System.Console.WriteLine ("Mthode static, Target = null") ; else if (ObjX.Equals(ObjA))System .Console.WriteLine ("Target rfrence bien ObjA") ; else System.Console.WriteLine ("Target ne rfrence pas ObjA") ; System.Console.WriteLine ( "\nnom : "+Elt.Method.Name ) ; System.Console.WriteLine ( "classe : "+Elt.Method.DeclaringType.ToString( ) ) ; System.Console.WriteLine ( "retour : "+Elt.Method.ReturnType.ToString( ) ) ; System.Console.WriteLine ( "----------------------------------") ; } System.Console.ReadLine ( ) ; } } }
rm di Scala - 2006
page
111
Nous voyons bien que le dlgu FoncDeleg contient la liste des rfrencements des mthodes meth100, meth101,meth102 et meth103 ordonn comme figur ci-dessous :
Remarquons que le premier objet de la liste est une rfrence sur une mthode de classe, la
)
page
112
proprit Target renvoie la valeur null (le champ _target est null). La mthode de classe meth103 ajoute en dernier est bien en tte de liste :
L'invocation du dlgu lance l'excution squentielle des 4 mthodes :
et le retour du rsutat est celui de meth103('a') :
Le parcours manuel de la liste montre bien que ce sont des objets de type Delegate qui sont stocks et que l'on peut accder entre autre possibilits, leurs proprits :
rm di Scala - 2006
page
113

Livret 03.2 Csharp

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Livret 03.2 Csharp

Transféré par

Droits d'auteur :

Formats disponibles

Livret 3.

Cours informatique programmation

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Classes, objets et mthodes

1. Les classes C# : des nouveaux types

2. Les objets : des rfrences ou des valeurs

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

1. Les classes : des nouveaux types

// les dclarations et implmentation des classes

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

1.4 Encapsulation des classes

Tableau des possibilits fourni par microsoft :

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Par dfaut la classe ApplicationClasse6 est ici private.

Un programme utilisant la classe ApplicationClasses : C# Explication

namespace Exemple { class AppliTestClasses { ApplicationClasses.ApplicationClasse2 a2; } }

Seule la classe interne ApplicationClasse2 est visible et permet d'instancier un objet.

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

C# dans le mme namespace

Une mthode dclare en abstract dans une classe mre :

N'a pas de corps de mthode. N'est pas excutable.

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Doit obligatoirement tre redfinie dans une classe fille.

Comparaison de dclaration d'abstraction de mthode en Delphi et C# : Delphi

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Rappel classes abstraites-interfaces

C# mthode virtuelle corps vide

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Java mthode virtuelle corps vide

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

2. Les objets : des rfrences ou des valeurs

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Situation aprs l'affectation " x = y "

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Exemple de constructeur avec instructions : C# class Un { public Un ( ) { a = 100 } int a; } Explication

Soit le dernier constructeur : public Un (int x , float y ) : this(y)

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

{ a = 100; } public Un (float b ) { a = (int)b; } public Un (int x , float y ) : this(y) { a += 100; } }

Dtaillons les instructions

Que se passe-t-il l'excution ?

x.a =12; System.Console.WriteLine("x.a="+x.a); System.Console.WriteLine("y.a="+y.a);

Comparaison Delphi - C# sur cet exemple (similitude complte) Delphi

Cas o le this sert outrepasser le masquage de visibilit : C#

Comparaison Delphi - C# sur ce second exemple (similitude complte aussi)

C# class Un { int a; public void methode(float a) { a = this.a + 7 ; } }

int b =15; a =.... ..... } }

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

struct AppliIn stance { int x ; int y ; }

Voici une image du segment de mmoire associ ces 3 objets :

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

class UtiliseApplistaticVar { int a ; void f( ) { a = ApplistaticVar.x ; ..... } }

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Rsum pratique sur les membres de classe en C#

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Rappel des notions de base Polymorphisme d'objet en C# : dfinitions

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005

Livret 3.2 : Le langage C# dans .Net : partie 2 - ( rv 07.12.2005