Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

UTILISATION DES MECANISMES DES LANGAGES OBJETS - CLASSES ABSTRAITES


Information sur le tutorial

Catégorie :Api Date de création : 01/08/2006 01:37:13 Vu : 10 606 fois

Note :
7 / 10 - par 2 personnes
7,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

Commentaire sur cette source (17)
Ajouter un commentaire et/ou une note

Description

Après la lecture de reférences sur java et autres langages objets où il est listé plus qu'expliqué l'usage des différents mots clés de l'approche objet, je suis resté sur ma faim de débutant à chaque fois. En effet q quoi sert tout ça? ou plutôt pourquoi ça existe?
La javadoc ou autres aides en ligne se contentent souvent d'exposer une syntaxe, et les forum ou autres faq montrent des exemples qui n'en disent souvent pas assez. Les outils donnés par les langages objet ont une génèse, et une utilité. Essayons de percevoir ça.

Tutorial

J'essaierai de traiter dans une série de tutorials les mécanismes des langages objet au fur et à mesure que je progresse dans leur compréhension.
la surcharge, les interfaces et l'utilisation du pattern adapter... pourraient être les suivants


Les classes abstraites.


Une classe abstraite, qu'est-ce que c'est? (reprise rapide de ce qu'on trouve partout)

C'est une classe où on laisse l'implémentation de certaines méthodes "vides" à ses descendantes.

Les méthodes à laisser "vides" doivent être specifiées abstract et ne  pas avoir de corps  {i.e.pas de  {code} ). Par exemple:

public
abstract void
methode();

Du coup, la classe doit être precédée du mot clé abstract sinon le compilateur empêche la compilation..

public
abstract class
ClasseAbstraite {....code...}

Les classes abstraites ça sert quand?(on ne trouve pas toujours ça)

Je ne pense pas pouvoir être exhaustif sur les usages des classes abstraites car je suis relativement neuf en java, mais en tentant de concevoir un code "beau", on réfléchit à ce que rien ne soit écrit plusieurs fois (factorisation du code). Et la factorisation, la réutilisation du code, c'est la raison d'être de tous les mécanismes propres aux langages objet, notamment les classes abstraites.

** lorsque, dans une classe on veut appeler une méthode du niveau de conception des descendantes  dans une methode appartenant au niveau de conception de la classe mère:(ouf ..)
exemple:
On imagine que l'on souhaite coder une méthode commune à tous les animaux dans une classe animal : la methode sAlimenter. Sachant que tous les animaux vont obtenirNourriture, ingurgiter,digérer, on aimerait écrire :

class Animal{
    ....code...
    public voidsAlimenter(){ //code du niveau de l'animal
    //le tralala qu'on ne voudra pas recoder ailleurs si c'est du niveau de Animal
        obtenirNourriture(); //à programmer au niveau de chaque descendant d'Animal
        ingurgiter(); //à programmer au niveau de chaque descendant d'Animal
        digérer(); //à programmer au niveau de chaque descendant d'Animal
   }
}

Les methodes obtenirNourriture, ingurgiter, digérerdoivent être disponibles au niveau du code de l'animal, ce qui evitera ainsi de recoder pour chaque sorte d'animal la méthode sAlimenter. Or on ne peut pas décider d'une implémentation des trois methodes appelées dans sAlimenter pour que l'organisation du code corresponde au niveau de concept d l'animal. Mais les langages objets disposent de l'outil classe abstraite, qui permet de coder en fonction de methodes vides comme ici.
Il suffi de rajouter après le code précédent la signature des méthodes que l'on souhaite appeler sans en connaitre l'implementation (pour réserver un point d'entrée pour l'implémentation, lorsqu'elle sera disponible dans une instance de classe descendante):

public abstract void obtenirNourriture();
public abstract void ingurgiter();
public abstract void digérer();

Or pour que la compilation se fasse, il faut rajouter abstract devant la declaration de la classe
Au final le code complet de notre classe abstraite :
abstract class Animal{
    ....code...
    public voidsAlimenter(){ //code du niveau de l'animal
   
//le tralala qu'on ne voudra pas recoder ailleurs si c'est du niveau de Animal
        obtenirNourriture(); //à programmer au niveau de chaque descendant d'Animal
        ingurgiter(); //à programmer au niveau de chaque descendant d'Animal
        digérer(); //à programmer au niveau de chaque descendant d'Animal
   }
   public abstract void obtenirNourriture(); //points d'entrée pour le code des classes enfants
   public abstract void ingurgiter();
   public abstract void digérer();
}

Question à deux balles pour mieux comprendre:

oui mais pourquoi pas une simple classe avec des implementation "creuses" comme   "public void obtenirNourriture() {};"  et qui seraient surchargées par les classes filles?

Pourquoi pas mais :
1.Si on laisse à quelqu'un d'autre le soin de coder les classes filles, comment être certain que les méthodes seront implémentées? La classe abstraite est un moyen de s'en assurer, car le compilateur veillera pour nous.
 
2.
Quand
on appelera un objet de type Chien en tant qu'Animal (inventaire d'une menagerie par exemple), ce sont ces méthodes vides qui seront appelées, et pas celles des instances. Exemple :
Chien instanceDeChien;
Chat instanceDeChat;
Serpent instanceDeSerpent;
Animal[] menagerie=[instanceDeChien,instanceDeChat,instanceDeSerpent];
Animal[1].ingurgiter(); //ne fera rien si surcharge d'une méthode vide, mais ingurgitera à la maniere de Chat si dérivation d'une classe abstraite.

Voilà n'hésitez pas à rajouter des questions pour la rubrique Questions à deux balles, ou vos remarques critiques qui me permettront de ne pas laisser trainer trop d'erreurs.





01 août 2006 01:46:36 :
retouches (titre, lignes inutiles supprimées... Ambiguités reformulées)
signaler à un administrateur
Commentaire de rebellus le 29/01/2007 07:49:26

salut tu peux faire un exemple sur un fichier java stp merci d'avance

signaler à un administrateur
Commentaire de jannoman le 12/02/2007 19:21:19

pour simplifier, je pense que les classs abstraites servent à faire des types disjonctifs (pour ceux qui connaissent CamL) : si tu as une variable qui peut faire soit un entier, soit un caractère (exemple : pour traiter des choses comme "3 + 4 -1", tu pourrais faire ce genre de distinction), et bien on aimerait avoir un type qui dise entier ou char, mais en java on fait souvent une classe contenant 2 champs (int n, char c) (plus un troisieme pour indiquer lequel des deux est celui en question (int selecteur qui vaut 0 si c'est n qui importe, 1 si c'est c).
mais le plus propre c'est de faire avec les classes abstraites :
classe Element dont vont hériter tes signes ou entiers, et la tu peux avoir un tableau, (ou mieux un arbre !) qui va coder ta formule, et dont les sommets/feuilles sont des Element.

signaler à un administrateur
Commentaire de pouicky le 12/02/2007 22:21:48

"pour simplifier", est une entrée en matière un peu trompeuse dans ta remarque.
Pour quelqu'un qui ne code pas ses propres opérateurs ni ses propres types, l'exemple semble loin d'être une simplification. Ceci dit, c'est une ouverture sur le monde CAML qui permet d'entrevoir la portée de la programmation objet.
Mais après avoir lu ton commentaire plusieurs fois, je ne vois pas vraiment si ton exemple illustre le polymorphisme de types et d'opérateurs, ou les expressions regulières... et on est loin de l'exemple que j'avais choisi sur des animaux. Et je ne vois pas non plus (parce que je ne code pas à un niveau aussi élémentaire) comment il caractérise l'utilisation des classes abstraites. Une illustration plus détaillée serait la bienvenue.

signaler à un administrateur
Commentaire de ouafaa83 le 15/07/2007 16:14:43

salut,
j'ai comme exposé:classe abstraite et illustration avec la classe "object" et des classes "Enveloppes", stp tu peut me donner quelques idées, conseils a propos de se sujet? merci d'avance

signaler à un administrateur
Commentaire de pouicky le 15/07/2007 23:19:47

Mais de quoi parle ton sujet?
Ta question est trop vague, et soit il s'agit de modifier le source  d'un TP, pour faire un découpage "beau" du code. ça peut se faire en rangeant le code dans le niveau conceptuel le plus adapté, comme par exemple, par la création de classes abstraites.
Les classes abstraites contiendront une pseudo implémentation de méthodes dont l'appel se traduira par l'appel de la même méthode dans les sous classes concrètes, avec leur implémentation particulière. Personne ne peut te répondre sur les classes object et enveloppes en dehors du contexte précis de ton exposé.
Ne s'agirait il pas d'un wrapper,tes enveloppes?

signaler à un administrateur
Commentaire de ouafaa83 le 22/07/2007 23:53:12

oui, c'est un wrapper, en fait,je veux savoir tout sur les classes enveloppe et la classe object,l'interet,les particularitées,l'utilisation...et bien sur des exemples exécutables.
merci

signaler à un administrateur
Commentaire de pouicky le 23/07/2007 01:20:00

Sur le lien suivant, une implémentation du pattern décorateur, ou encore wrapper sur la classe TableModel:
http://java.sun.com/docs/books/tutorial/uiswing/examples/components/TableSorterDemoProject/src/components/TableSorter.java
Le code est poussé, mais la description, faite par des pros de chez sun (en anglais) est assez claire et décrit bien la conception de la classe en tant que décorateur de TableModel;

Il s'agit d'ajouter des fonctionnalités à une classe TableModel, en créant une classe capable de la "décorer" avec des fonctionnalités de tri supplémentaires.

Cette classe est dérivée d'une classe abstraite, AbstractTableModel, et utilise pour tableModel celui passé au constructeur,qu'on veut décorer.

Ce pattern (décorateur ne me semble pas typique de l'usage des classes abstraites, mais tous les avis sont possibles.)

Un tour vers les design patterns et notamment le pattern template, te fera voir un usage des classes abstraites:
http://abrillant.developpez.com/tutoriel/java/design/pattern/introduction/#L3.3

Pour la classe Object en java, c'est la mère de toutes les classes - une conséquence pratique, par exemple: Un tableau de type Object[] permet de stocker tout type d'objet.
--> chercher javadoc/object dans google

Voilà quelques pistes. Pour les exemples executables, il faudrait ecrire un petit morceau de traitement à améliorer en utilisant tour à tour un décorateur, des classes abstraites...(pourquoi pas des animaux? ;)
Du code redondant au départ, sans hierarchie de classes:
Classes Chat, Oiseau, Poisson avec des méthodes voler, nager, marcher.
Des instances de chaque animal et puis un boucle sur chaque animal pour les faire se déplacer --> nécéssité de faire un appel à une méthode commune, implémentée différemment pour chaque animal.
Soit on redefini une hierarchie de classes avec un classe abstraite "Animal" héritée diffémment pour chaque classe "Animal"
Ou bien on garde chaque méhode (pour compatibilité avec un existant par exemple) et on utilise un adaptateur qui oblige à définir dans chaque classe la méthode commune.
Si on cherche de la robustesse, on utilise alors des contraintes d'implémentation d'interfaces pour ces classes (Interface AnimalMobile, par exemple, avec methode "seDéplacer" à implémenter). Le code ne se lancera pas sans que toutes les classes n'implémentent leurs interfaces.
En jouant avec des sorties texte "je vole, je me déplace, je suis décoré avec un manteau pour chat...), ça devrait etre vivant et digeste."

signaler à un administrateur
Commentaire de pouicky le 23/07/2007 01:43:10

ici une tres bonne explication (en anglais, forcément, quand on cherche "wrapper")
http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/DecoratorPattern.htm

Le paragraphe de description est assez clair et précis. On y lit que Le décorateur est assimilable à l'objet qu'il décore car il implemente les memes méthodes (plus d'autres). Il est dit aussi que les décorateurs sont souples d'utilisation, car ils peuvent se combiner sur un décoré sans que le reste du code ne soit impacté.
Enfin, il semble que le décorateur soit un descendant d'une même classe abstraite que le décoré. (il y aurait donc un rapport étroit entre wrapper et classes abstraites)
Bon courage.

signaler à un administrateur
Commentaire de ouafaa83 le 23/07/2007 11:46:19

excusez moi, je ne vois pas encore la relation entre les classes abstraites et la classe object d'une part, et entre les classes astraites et les classes enveloppes d'autre part!!
durant ma recherche sur le sujet,j'ai trouvé pour la classe Object que c'est,comme vous l'avez dit, la mère de toutes les classes,c-à-d que toutes les classes héritent de object, tout ce qui est défini dans cette classe sera donc utilisable dans tous les objets que nous créerons, puisqu'ils en hériteront tous.mieux encore, quand on déclare une classe sans la faire hériter explicitement de Object, le compilateur se charge de le rajouter. Une classe hérite toujours implicitement de Object.
j'ai trouvé une information que je n'ai pas saisie c'est:
"une variable de type Object peut être utilisée pour référencer un objet de type quelconque :
                              Point p = new Point (...) ;
                              Pointcol pc = new Pointcol (...) ;
                              Fleur f = new Fleur (...) ;
                              Object o ; o = p ; OK
                              o = pc ; OK
                              o = f ; OK
Cette particularité peut être utilisée pour manipuler des objets dont on ne connaît pas le type exact (au moins à un certain moment). Cela pourrait être le cas d'une méthode qui se contente de transmettre à une autre méthode une référence qu'elle a reçu en argument. Bien entendu, dès qu'on souhaitera appliquer une méthode précise à un objet référencé par une variable de type Object, il faudra obligatoirement effectuer une conversion appropriée. Voyez cet exemple où l'on suppose que la classe Point dispose de la méthode déplace

                                 Point p = new Point (...) ;
                                      Object o ;
                                        ...
                                o = p ; o.déplace() ; erreur de compilation
                                ((Point)o).déplace() ; OK en compilation (attention aux parenthèses)
                                 Point p1 = (Point) o ; OK : idem ci-dessus, avec création d'une référence
                                 p1.déplace() ; intermédiaire dans p1    "

Voila, et surtout ce dernier exemple qui ma posé de problèmes!!!
une autre phrase qui dise
"Tous les objets, incluant les tableaux, implémente les méthodes de la classe object.
Tout type tableau dérive également de Object. Par suite, toute méthode déclarée avec un paramètre de type Object accepte en argument un tableau quelconque ou un objet de n'importe quelle classe, mais pas une valeur d'un type primitif."

vous pouvez me donner une explication plus claire?
et merci pour tout





signaler à un administrateur
Commentaire de pouicky le 24/07/2007 01:20:37

Je viens de faire une petite source simple avec des animaux illustrant l'évolution du code en partant d'un code linéaire et redondant pour le corriger avec l'abstraction puis la décoration.
on peut le voir ici:
http://www.javafr.com/code.aspx?ID=43554

Pour ce qui est du rapport entre la classe Objetc et les classes abstraites je ne vois pas trop. Peut etre est-ce que la classe Object est une abstraction de toutes les autres sur un plan conceptuel?

signaler à un administrateur
Commentaire de ouafaa83 le 24/07/2007 03:20:07

je dirais plutot que la classe Object est une classe abstraite! puisqu'on ne peut pas l'instancier, mais je ne vois pas la relation entre les classes abstraites et des enveloppes, je peut vous dire que les classes enveloppes Byte, Short, Integer, Long, Float et Double sont tous des déscendants de la classe Number qui est une classe abstraite...

signaler à un administrateur
Commentaire de pouicky le 24/07/2007 12:11:26

//on peut instancier un objet de classe Object :
public class Lanceur {
  public Lanceur() {
  }
  
//Méthode main
  public static void main(String[] args) {
      Object a=new Object();
      System.out.println(a.toString());
  }
}
Alors non je vois toujours pas le probleme que tu as avec la classe object, désolé.

signaler à un administrateur
Commentaire de sheorogath le 15/08/2007 00:33:45 administrateur CS

ta pas parler des interfaces ...
sinon c'est pas mal , je n'ai fais que survoler masi ca a l'air bien

signaler à un administrateur
Commentaire de pouicky le 17/08/2007 00:09:45

Tu as raison, j'avais promis. Mais les aléas de la vie me tiennent trop souvent éloigné de ce doux loisir qu'est la programmation. Alors dès que je peux, je m'y penche.
   Cependant, au sujet des interfaces, je suis encore innocent et je ne vois pas clairement les cas où elles seront préférées à d'autres outils. J'ai voulu m'y intéresser plus après une phrase de Delphiprog (Codes sources delphi) qui prône la programmation d'interfaces plutôt que le codage de classes. Dans l'état actuel de mes connaissances, il me semble que c'est un outil qui améliore la souplesse d'un code et sa maintenance, sur une durée de vie longue; qui permet d'imposer des contraintes d'implémentation à une équipe de dev mais sur des petits projets perso, quand sont-elles incontournables?
   Merci de tes encouragements. Je suis de mon côté impressionné par ton jeune âge, le nombre et la technicité de tes sources. Chapeau bas. Ne te laisse pas pour autant avaler par ton écran ;)

signaler à un administrateur
Commentaire de zarkofaj le 16/10/2007 07:01:58

Excellente explication. Merci bien .

signaler à un administrateur
Commentaire de sheorogath le 17/10/2007 00:14:56 administrateur CS

merci pour le compliment , disons que je travail et que pour certain trucs j'ai eut une aide precieuse qui m'a ouvert les yeux sur quelques truc en prog

sur les petits projet elles ne sont pas tres utile c'est vrai mais sur les un peu plus gros ca donne une code plus propres avec des dependances interclasse beaucoup plus claire et mieu gerees

sinon pour l'ecran t'inquiete pas , je continue a essayer de lui imposer ma volonte ^^

bonne soiree++

signaler à un administrateur
Commentaire de bernardGigi le 24/01/2008 12:53:49

Excellent, tu peux aussi dire (pour les plus forts) que ton exemple n'est rien d'autre que le design pattern patron de méthode (template method).
Bravo

Ajouter un commentaire



Nos sponsors

Sondage...

CalendriCode

Septembre 2008
LMMJVSD
1234567
891011121314
15161718192021
22232425262728
2930     

Consulter la suite du CalendriCode



Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel BAÏSE, Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,22 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.