[POO] Besoin d'éclaircissements.

Bonjour,

Je me pose une question à propos de quelque chose que je vois très souvent en Java, et je voudrais savoir si c'est parce que c'est java ou parce que c'est la poo.

On a une classe abstraite A, et une classe B qui hérite de A.

Très souvent donc, on trouvera :

Code:

---

1 2	A maclasse = new B();

---

Pour quelle raison fait-on ça ?

Il est très probable que B contienne des méthodes qui ne sont pas dans A, et donc déclarer maclasse comme ça ne permet pas d'utiliser ces méthodes.

Sauf si on caste maclasse en B, ce qui du coup devient franchement n'importe quoi.

L'abstraction, d'apres moi, c'est très bien quand justement on veut généraliser. Par exemple, s'il y a 20 classes qui héritent de A, et qu'on veut dans une fonction juste appeller une méthode qui est déjà dans A, on a, à ce moment là, pas besoin de savoir quelle classe c'est.

Par contre instancier volontairement une classe en se privant de ses membres, je ne vois pas l'astuce.

Donc, vu que j'ai probablement mal compris l'idée générale, si une bonne âme pouvait m'éclairer, je lui en serait reconnaissant.

Merci

Pour rendre l'exemple plus clair, il suffit d'imaginer que plusieurs classes étendent A, donc :

Code:

---

1 2 3 4

class B extends A class C extends A etc...

---

Maintenant, imagine qu'on veuille traiter un liste d'objets B, C, ... par leur fonctionnalités A (issues de A)
On peut faire

Code:

---

1 2 3 4 5

for (A item : listeDeBC) { item.fonctionDeA(); }

---

C'est "un peu" le même principe qu'avec une interface...

J'espère avoir été assez clair...
A+

Citation:

---

Envoyé par Faiche

L'abstraction, d'apres moi, c'est très bien quand justement on veut généraliser. Par exemple, s'il y a 20 classes qui héritent de A, et qu'on veut dans une fonction juste appeller une méthode qui est déjà dans A, on a, à ce moment là, pas besoin de savoir quelle classe c'est.

---

A priori tu as très bien compris le pourquoi du comment.
C'est juste qu'on sait qu'on a un véhicule, et qu'on veut le faire avancer, reculer, tourner, freiner, peu importe que ce soit une moto, un quad, une voiture ou un camion.
La seule contrainte, c'est qu'il faut que la classe hérite d'une classe particulière.
Et si tu veux aller plus loin, et que tu ne veux pas cette contrainte, et bien on utilise une interface.
On sait pas qui c'est, mais il doit remplir le contrat, l'interface.
Cela permet d'étendre des implémentations possibles d'un même contrat.

Citation:

---

Envoyé par OButterlin

Pour rendre l'exemple plus clair, il suffit d'imaginer que plusieurs classes étendent A, donc :

Code:

---

1 2 3 4

class B extends A class C extends A etc...

---

Maintenant, imagine qu'on veuille traiter un liste d'objets B, C, ... par leur fonctionnalités A (issues de A)
On peut faire

Code:

---

1 2 3 4 5

for (A item : listeDeBC) { item.fonctionDeA(); }

---

C'est "un peu" le même principe qu'avec une interface...

J'espère avoir été assez clair...
A+

---

En fait c'est pas du tout ça.

Dans ton exemple, c'est de l'abstraction, pour généraliser une action, parce que tu n'utilises qu'une fonction qui est décrite dans la classe mère ou dans l'interface. Et c'est l'utilisation évidente.

Mon problème à moi, c'est quand on trouve des trucs comme ça :

Code:

---

1 2	List<A> list = new ArrayList<A>();

---

etc..

Du coup, list n'aura accès qu'aux méthodes de List, mais pas de ArrayList.

Donc je vois pas l'interet.

Citation:

---

Envoyé par Faiche

Mon problème à moi, c'est quand on trouve des trucs comme ça :

Code:

---

1 2	List<A> list = new ArrayList<A>();

---

etc..

Du coup, list n'aura accès qu'aux méthodes de List, mais pas de ArrayList.

Donc je vois pas l'interet.

---

L'intérêt est de ne être dépendant de ArrayList, et de se laisser la possibilité d'utiliser éventuellement quelque chose de plus optimisé ou de plus approprié.

Petit aujout pour le cas des interfaces :

Dans 98% des cas je déclare mes collections/maps comme celà :

Code:

---

Collection c = new LinkedHashSet();

---

Derrière tu ne manipules plus que l'interface Collection, tu brises ainsi la dépendance directe que tu as avec l'implémentation "LinkedHashSet". Si demain tu veux que ta collection soit automatiquement triée, tu modifies la déclaration LinkedHashSet en TreeSet et le tour est joué !

Citation:

---

Envoyé par Duc Lebowski

Petit aujout pour le cas des interfaces :

Dans 98% des cas je déclare mes collections/maps comme celà :

Code:

---

Collection c = new LinkedHashSet();

---

Derrière tu ne manipules plus que l'interface Collection, tu brises ainsi la dépendance directe que tu as avec l'implémentation "LinkedHashSet". Si demain tu veux que ta collection soit automatiquement triée, tu modifies la déclaration LinkedHashSet en TreeSet et le tour est joué !

---

Bon, jusque la j'avais bien compris que comme ça, on sait pas du tout si on utilise un linkedhashset ou va savoir quoi.

Maintenant, t'as dans les mains une collection, et tu veux utiliser une méthode qui est spécifique a linkedhashset, tu fais quoi ?

Citation:

---

Envoyé par Faiche

Maintenant, t'as dans les mains une collection, et tu veux utiliser une méthode qui est spécifique a linkedhashset, tu fais quoi ?

---

Soit tu es cohérent, et tu n'as qu'une collection, point barre.
Soit tu test que c'est bien une classe spécifique que tu connais, et là si c'est nécessaire, tu peux utiliser une fonctionnalité particulière. Mais il faut éviter les castages sauvages...

Depuis 5 ans que je développe en Java, je crois que je n'ai jamais eut à appliquer une méthode spécifique sur une implémentation de Collection... ;)

Par défaut je manipule toujours l'interface. Si demain je dois appeler une méthode spécifique alors je reverrai ma conception.

Et puis c'est le principe d'inversion des dépendances (DIP) :

A. Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Tous deux doivent dépendre d'abstractions.

B. Les abstractions ne doivent pas dépendre de détails. Les détails doivent dépendre d'abstractions.

Vas faire un petit tour ici, tout est dit !

Ok.

Bon, je comprends l'idée du coup.

Je vais déclarer tous mes objet en Object maintenant :p

Enfin bon, merci pour l'explication :)

bonjour,

effectivement il peut y avoir une utilité à utiliser le polymorphisme de cette façon encore un exemple :

http://abrillant.developpez.com/tuto...oduction/#L3.1

Citation:

---

Je vais déclarer tous mes objet en Object maintenant :p

---

:lol:

Salut,

Citation:

---

Envoyé par Faiche

Maintenant, t'as dans les mains une collection, et tu veux utiliser une méthode qui est spécifique a linkedhashset, tu fais quoi ?

---

Dans 99% des cas tu te contentes des méthodes décrites dans l'interface que tu utilises. Pour info il ne me semble pas que LinkedHashSet propose des méthodes supplémentaires, mais ta question n'en est pas quand même très pertinente...

Parfois l'abstraction systématique peut en effet être abusive, en particulier dans la déclaration d'un variable (j'y reviendrais un peu plus loin), mais lors de l'utilisation d'un paramètre de méthode ou de son type de retour.


Imaginons une méthode qui permette de calculer le prix d'une liste de produit :

Code:

---

1 2 3 4 5 6 7

public double calculerPrixTotal(ArrayList<Produit> listeProduits) { double montant = 0.0; for (Produit p : listeProduits) { montant += p.getQuantite() * p.getPrix(); } return montant; }

---

Rien de bien compliqué, mais comme elle utilise une ArrayList ta méthode a un gros défaut : elle se limite justement aux ArrayList !

:arrow: Si pour une raison X ou Y je dois utiliser un autre type de collection (par exemple une LinkedHashSet), je ne pourrais plus utiliser ta méthode directement et je devrais passé par une collection intermédiaire :

Code:

---

1 2 3

LinkedHashSet<Produit> set = ...;   double prix = calculerPrixTotal( new ArrayList<Produit>(set) );

---

:arrow: Ce qui est non seulement pas très pratique, mais provoque également une duplication inutile...

Dans cet exemple la méthode calculerPrixTotal() utilise abusivement le type ArrayList, car elle attend simplement une liste de produit quelquonque, et devrait donc utiliser plutôt une Collection : après tout pour faire une somme quel intérêt y a t-il de savoir avec précision comment sont "rangés" les produits, du moment qu'on peut les lister...

Mieux, avec Java 5.0 on pourrait se contenter d'utiliser Iterable qui décrit simplement la méthode iterator() :

Code:

---

1 2 3 4 5 6 7

public double calculerPrixTotal(Iterable<Produit> listeProduits) { double montant = 0.0; for (Produit p : listeProduits) { montant += p.getQuantite() * p.getPrix(); } return montant; }

---

:arrow: Désormais notre méthode calculerPrixTotal() est générique et peut être utilisée avec n'importe quel type de collection d'objet...







Maintenant il y a certains cas où cette abstraction peut être abusive, justement dans le cadre d'une variable locale où on est plus proche.

Prenons le cas de la méthode suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10

public List<Produit> creerListeProduit() { List<Produit> list = new ArrayList<Produit>();   // Récupération de la liste des produits (depuis une BD, un fichier, etc... while (...) { list.add(produit); }   return list; }

---

:arrow: Le code est bien générique puisqu'on utilise List en type de retour et non pas ArrayList, mais en interne il serait intérressant d'utiliser une ArrayList. En effet les ArrayList utilise un tableau pour stocker les valeurs, et ce dernier est doublé à chaque fois qu'il est "plein", et possède donc un certain nombre d'emplacement 'inutile' en particulier si la liste ne sera plus modifié par la suite.

On peut corriger cela en utilisant la méthode trimToSize() spécifique aux ArrayList, mais il faut conserver son type dans la méthode :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public List<Produit> creerListeProduit() { ArrayList<Produit> list = new ArrayList<Produit>();   // Récupération de la liste des produits (depuis une BD, un fichier, etc... while (...) { list.add(produit); }   // On 'élimine' les emplacements inutiles : list.trimToSize();   return list; }

---

Bref : en interne on peut avoir besoin de connaitre le type précis afin d'utiliser certaines de ses spécificités, mais dans 99% des cas on se fiche pas mal de son implémentation et il est préférable d'utiliser un des types de base pour une plus grande généricité...


Maintenant, dans le doute il faut priviliéger l'abstraction car il y a bien moins de conséquence dans le fait de changer le type d'une variable locales que de modifier les types des paramètres et valeur de retour de méthodes public (cela provoque une incompatibilité).


a++


PS : comme d'hab j'ai fait un gros pavé et le sujet est résolu :aie:

Citation:

---

Envoyé par adiGuba

PS : comme d'hab j'ai fait un gros pavé et le sujet est résolu :aie:

---

:lol: c'est pas grave, y a eu des réponses abstraites et la tienne est concrète.

Avec un très bon exemple c'est clair que c'est plus parlant !