Cours java les concepts-descriptions d’Eiffel, tutoriel & guide de travaux pratiques en pdf.

Les descriptions

Nous nommerons désormais concepts-descriptions les types de descriptions.

Présentation

Nous venons de présenter plusieurs exemples de concepts-relations ti-rés des langages Eiffel et Java. Nous avons, à cette occasion, vu que ces concepts-relations s’appliquent souvent entre des classes, mais pas toujours. Le concept-relation d’implémentation de Java (cf. section 2.3 page 9), s’il a pour source une classe, gère un ensemble d’interfaces comme cibles. Nous ap-pelons ces différentes sortes d’entité des concepts-descriptions.
Comme pour les concepts-relations, nous donnons ci-dessous un ensemble des concepts-descriptions d’Eiffel puis de Java. Voici les points que nous avons considérés comme essentiels dans la présentation de ces concepts-descriptions :
– S’agit-il d’un concept-description simple c’est-à-dire associé à un seul type, ou multiple, associé à plusieurs types16. ?
– Ce concept-description a-t-il la capacité de créer des instances propres ?
– A-t-il la possibilité des les détruire ?
– Les primitives sont-elles encapsulées dans les descriptions ? Rappelons que tous les concepts de classe ne sont pas encapsulant. Par exemple, CLOS n’encapsule pas les méthodes.
– Les attributs et/ou les méthodes sont-ils permis ? d’instance unique, d’instance ou de description ou plusieurs de ces possibilités ?
– La description permet-elle la surcharge, c’est-à-dire la capacité de possé-der plusieurs méthodes de même nom différent par le nom et/ou le type de leurs paramètres ?
– Quelle est la visibilité de cette description ? C’est-à-dire à partir d’où peut-on y accéder ?
– Enfin, pour chaque concept-description, nous associons une liste des concepts-relations qui peuvent être utilisés en prenant le concept-des-cription comme source. Une seconde liste réalise la même chose pour les cibles.

Les concepts-descriptions d’Eiffel

Nous décrivons dans cette partie neuf concepts-descriptions pour Eiffel . Nous nous attacherons tout d’abord à préciser les caractéristiques des classes puis nous établirons des distinctions selon qu’elles sont abstraites, génériques ou expansées. Nous nous intéresserons ensuite à des cas particuliers : les types fondamentaux, les types binaires et néant.
classe C’est le concept-description essentiel d’Eiffel . Il est possible de le voir comme une description de la structure (les attributs) et du comporte-ment (les méthodes) de ses instances. Il peut également être vu comme un conteneur de celles-ci, un peu particulier il est vrai, puisqu’il ne peut fournir son contenu. Imaginons donc, pour ce premier exemple, une classe C (non générique, non abstraite et non expansée). Nous pouvons décrire le concept-description correspondant de la manière suivante :
– simple (C est associé à un seul type),
– générateur (C se charge de la création de ses instances propres),
– non destructeur (C ne peut détruire ses instances. Eiffel , comme d’autres langages à objets possède un ramasse-miettes qui se charge de libérer la mémoire utilisée par les objets qui ne sont plus référen-cés. Il est donc inutile, et ce serait d’ailleurs dangereux, de permettre au programmeur de détruire des instances. D’autres langages, comme C++ ne dispose pas de ramasse-miettes généraux et la destruction doit donc parfois être faite explicitement par le programmeur, à ses risques et périls.),
– encapsulant (tout attribut et toute méthode associée aux instances de C est décrite dans C),
– attributs et méthodes autorisés,
– autorise les attributs d’instance unique (expansé) ou d’instance,
– surcharge interdite,
– global (la classe est directement accessible par toute autre classe),
– concepts-relations valides en tant que :
source directe : héritage (cf. page 4), clientèle (cf. page 5) et clientèle expansée (cf. page 6) ;
cible directe : héritage, clientèle, clientèle expansée et généricité (cf. page 6).
classe abstraite Les classes abstraites (mot-clé deferred) constituent un premier cas particulier de classe. Elles ne sont pas complètement spé-cifiées et sont dites différées ou retardées car leur spécification doit être précisée (concrétisée) par une autre classe. Cette incomplétude ne leur permet pas de créer des instances ; elles possèdent cependant les ins-tances indirectes de leurs héritières non abstraites. Soit un classe abs-traite C (non générique et non expansée), le concept-description classe abstraite est :
– simple,
– non générateur (C ne peut créer d’instance propre),
– non destructeur,
– encapsulant,
– attributs et méthodes (il faut au moins une méthode abstraite dans C ou dans une des ses classes héritées) autorisés,
– autorise les attributs d’instance unique ou d’instance,
– surcharge interdite,
– global,
– concepts-relations valides en tant que :
source directe : héritage (cf. page 4), clientèle (cf. page 5) et clientèle expansée (cf. page 6) ;
cible directe : héritage, clientèle et généricité (cf. page 6).
classe générique Une des capacités très utiles d’Eiffel est la possibilité de déclarer des classes génériques. Voyons donc maintenant comment nous pouvons décrire une classe générique C (non abstraite et non expansée).
– multiple (C est associé à autant de types qu’il y a de combinaisons différentes des types des paramètres génériques effectifs lors de l’exé-cution de l’application),
– générateur,
– non destructeur,
– encapsulant,
– attributs et méthodes autorisés,
– autorise les attributs d’instance unique ou d’instance,
– surcharge interdite,
– global,
– concepts-relations valides en tant que : source directe : tous.
cible directe : héritage (cf. page 4), clientèle (cf. page 5), clientèle ex-pansée (cf. page 6) et généricité (cf. page 6).
classe abstraite générique Il s’agit d’une composition de classe abstraite (cf. page 14) et de classe générique (cf. page 14). Voici les caractéristiques particulières à cette sorte de description, nous oublierons tout ce qui est commun à classe abstraite et à classe générique :
– multiple,
– non générateur,
– attributs et méthodes (au moins une méthode abstraite) autorisés,
– concepts-relations valides en tant que : source directe : tous.
cible directe : héritage (cf. page 4), clientèle (cf. page 5) et généricité (cf. page 6).
classe expansée Le dernier cas particulier de classe est constitué par les classes expansées (mot-clé expanded). Elles permettent notamment de décrire élégamment les types de base d’une application. Décrivons donc une classe expansée C.
– simple,
– générateur,
– non destructeur,
– encapsulant,
– attributs et méthodes autorisés,
– n’autorise que les attributs d’instance unique,
– surcharge interdite,
– global,
– concepts-relations valides en tant que :
source directe : héritage (cf. page 4), clientèle (cf. page 5) et clientèle expansée (cf. page 6) ;
cible directe : héritage, clientèle expansée et généricité expansée (cf. page 7).
classe expansée générique Elles possèdent les caractéristiques à la fois des classes expansée (cf. page 15) et des classes génériques (cf. page 14) :
– simple,
– n’autorise que les attributs d’instance unique,
– concepts-relations valides en tant que : source directe : tous.
cible directe : héritage (cf. page 4), clientèle expansée (cf. page 6) et généricité expansée (cf. page 7).
type fondamental En Eiffel , certains types sont considérés comme fonda-mentaux. Ils représentent les entités de base de l’application. Les types fondamentaux (également appelés classes fondamentales) permettent de manipuler les valeurs les plus couramment utilisées : nous y trouvons ainsi les booléens, les caractères, les flottants17 (simples et doubles) et les pointeurs. Ces classes peuvent être considérées comme normales à ceci près :
– Elles disposent d’une interface syntaxique particulière : des mots-clés leur sont associés (exemples : true) et surtout, il est possible d’utiliser directement des constantes de leur type (exemples : 12 est reconnu comme un entier).
– Chacune est expansée et hérite d’une classe non expansée sans en modifier autrement l’interface. Il est donc possible d’utiliser plutôt les classes héritées si nous voulons manipuler une valeur fondamentale comme un objet normal (i. e. référencé).
– Bien qu’il n’y ait aucune relation d’héritage entre les classes fonda-mentales, les entiers sont considérés comme18 des flottants simples et les flottants simples comme des flottants doubles. Il ne s’agit ce-pendant que de respecter une convention humaine bien pratique qui décrit l’ensemble des réels comme incluant celui des entiers.
– concepts-relations valides en tant que :
source directe : non applicable (il n’est pas possible de créer un nou-veau type fondamental) ;
cible directe : héritage (cf. page 4), clientèle expansée (cf. page 6) et généricité expansée (cf. page 7).
type binaire Les types binaires sont d’un usage très spécialisé et forment un cas très particulier. Ils permettent de décrire et manipuler des objets de type suite de n bits19. Leurs particularités sont :
– Aucune classe n’existe pour décrire un objet de type suite de n bits avant que celui-ci ne soit déclaré. Après sa déclaration, tout se passe cependant comme si une telle classe existait et un certain nombre de primitives est donc disponible.
– Bien qu’il soit possible de s’en servir comme si elles existaient, ces classes ne sont que virtuelles et ne font donc pas partie de l’arbre d’hé-ritage. Il est néanmoins considéré qu’elles descendent directement de la classe racine.
– Bien entendu, ces classes, qui n’existent pas, n’héritent de rien sauf de la classe racine ANY. Cependant, dans un souci de les rendre pratiques à utiliser, il est possible de considérer tout objet de type suite de n bits comme un objet quelconque (de la classe racine donc) ou comme un objet de type suite de m bits, à la condition sine qua none que n m.
– concepts-relations valides en tant que :
source directe : non applicable (il n’est pas possible de créer un nou-veau type binaire) ;
cible directe : clientèle expansée (cf. page 6).
néant Il n’est pas possible de terminer cette liste sans citer le cas très par-ticulier de la classe NONE qui est une classe fictive utile pour le graphe de type. Elle hérite automatiquement (et en ignorant tous les conflits) de toutes les classes de l’application (donc, à cause de la non-circularité, aucune classe ne peut en hériter) et n’exporte aucune primitive. De plus, elle ne possède qu’une seule instance, nommée void, qui sert de valeur par défaut à tout objet non initialisé.
– concepts-relations valides en tant que :
source directe : non applicable (il n’est pas possible de créer un nouveau néant) ;
cible directe : clientèle (cf. page 5).
Enfin, précisons que les classes représentant les tableaux et les chaînes de caractères constituent des cas particuliers en Eiffel , mais cela n’est vrai que du point de vue syntaxique : des facilités sont offertes au programmeur pour exprimer des constantes de ces types. Du point de vue sémantique, ces classes sont standards et ne sont pas traitées de manière particulière par le compilateur.

Les concepts-descriptions de Java

Nous présentons maintenant dans cette partie treize concepts-descriptions pour Java comme nous l’avons fait dans la section précédente pour Eiffel .
classe C’est un concept-description proche de celui d’Eiffel . Prenons comme premier exemple une classe C. Nous pouvons décrire le concept-description correspondant de la manière suivante :
– simple,
– générateur,
– non destructeur (présence d’un ramasse-miettes),
– encapsulant,
– attributs et méthodes autorisés,
– autorise les attributs d’instance ou de description,
– surcharge autorisée, le type de la valeur de retour n’étant pas pris en compte,

1 Introduction 
2 Les relations
2.1 Présentation
2.2 Les concepts-relations d’Eiffel
2.3 Les concepts-relations de Java
3 Les descriptions 
3.1 Présentation
3.2 Les concepts-descriptions d’Eiffel
3.3 Les concepts-descriptions de Java
4 Conclusion