Discussion :

[cotmar]

Bonjour,

Je suis sur un projet avec un objet article qui doit-être soit un "article d'occasion", soit un "article neuf". Article est une classe abstraite avec comme sous classes (lien d'héritage) : Livre, Film, Musique...

Quelle est la meilleure solution s'il vous plaît ?

Par avance je vous remercies.

Cordialement.

Marco.

[Nico02]

Quelle est la question au final ? Que viens faire une interface la dedans ?

La question qu'il faut se poser est :

"Est-ce qu'il y a des différences autres que que le status de l'article (neuf ou non) ?"

Car si il n'y en a aucune tu peux simplement rajouter un attribut de classe qui définie ce statut.

Si il y en a, dans ce cas il faut faire une sous classe de article.

[joel.drigo]

Salut,

la meilleure solution de quoi pour quoi faire ?

Si ta question concerne le choix de l'emploi d'une Interface ou d'une classe Abstraitre, pour moi ce choix ne concerne pas le modèle de données, mais l'implémentation du code.

On utilise une Interface pour définir des objets qu'on veut manipuler mais dont on ne veut pas imposer l'implémentation : l'Interface permet d'imposer un moyen de récupérer des informations ou d'engager des traitements...

On utilise une classe abstraite lorsqu'en plus on veut imposer l'implémentation d'une partie de ces objets, comme un traitement particulier par exemple.

Par contre pour modéliser une hiérarchie d'objets média comme Livre, Film, Musique, on peut créer une hiérarchie de classes (ou même une seule classe si les informations et les traitements sont les mêmes pour tous les éléments).

Ensuite 2 conditions peuvent amener à avoir une abstraction (ou une interface) comme racine de la hiérarchie :

- ne pas imposer l'implémentation (par exemple tu fais toi une implémentation avec une classe ou tu stocke les valeurs dans des variables de classes, mais tu te dis que quelqu'un voudrait pouvoir faire un adapteur pour un bean à lui et utiliser ton API, ou autre que justement tu estimes ne pas pouvoir prévoir
- ne pas permettre d'instancier la classe racine de ta hiérarchie, auquel cas , ou un contructeur protected ou package suffira (c'est contournable certes, mais éventuellement il y'a la solution de la fabrique et la classe private, mais tu interdis la possibilité d'ajouter de nouveau média pour un utilisateur de ton API).

[cotmar]

Bonjour et merci tout d'abord pour votre réponse rapide,

Je pense que j'aurais dû préciser le contexte de mon projet. Il s'agit de créer un site internet de vente en ligne pour une boutique du genre "Gibert Jeunes" (pour ceux qui connaissent). Je fais ça à titre personnel. Dans mon site on vend des bien qui peuvent-être neufs ou d'occasion (pour calculer le prix, j'applique simplement une coefficient en fonction de la rareté et de l'usure).

En fait j'ai une hiérarchie de classes entre une classe mère Article (classe abstraite) et des classes filles : Livre (papier et électronique), Film (DVD, Blue Ray, Laser Disc), Musique (CD, vinyl), affiche (grande, moyenne, petite) et place de concert. Les formats listés entre parenthèses sont des classes énumérées ainsi que les différents taux de TVA.

J'aurais voulu traiter différemment les cas des articles d'occasion et des articles neufs. Sachant qu'il y a des propriétés et des méthodes légèrement différentes entre les deux, en cherchant un peut sur le Web, j'avais imaginer régler ce problème en utilisant des interfaces. Ce n'est peut-être pas ce qui est le plus adapté ? Pouvez vous me conseiller s'il vous plaît ?

Mais là il me faut impérativement avoir une relation avec un exclusivité entre l'un ou l'autre cas (car il va sans dire que un article ne peut pas être à la fois neuf et d'occasion).

Ma réflexion en est là et je suis un peut bloqué à ce point au niveau de mon diagramme de classes et des classes que j'ai commencé à implémenter.

Par avance je vous remercies.

Cordialement.

Marco.

[joel.drigo]

On peut effectivement faire une hiérarchie d'interfaces du type :

IArticle
IArticleNeuf extends IArticle
IArticleOccasion extends IArticle

mais ça oblige de dupliquer toutes les classes de la hiérarchie (représentant chaque média) pour avoir une hiérarchie de neuf et une hiérarchie d'occaz

Moi je ferais tout simple 2 classes en plus de la classe de la hiérarchie de classes représentant chaque média, éventuellement héritant de la même abstraction pour pouvoir être manipuler indépendemment du caractère neuf ou occaz.

Genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public abstract class Produit {
 
   private IArticle article;
 
   public Produit(IArticle article) { this.article = article;}
 
   public IArticle getProduit() {
       return article;
   }
 
 
 
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class ProduitNeuf {
 
   public ProduitNeuf(IArticle article) {
       super(article);
   }
 
   ... les méthodes spécifiques au neuf
 
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class ProduitOccaz {
 
   public ProduitOccaz(IArticle article) {
       super(article);
   }
 
   ... les méthodes spécifiques à occaz
 
}

Dans ce cadre, IArticle n'est pas obligatoirement une interface, c'est pour l'exemple...

[tchize_]

Faut voir aussi, des situation "légèrement" différente ne nécessitent pas nécessairement d'avoir une hierarchie à part. Je commencerais par mettre simplement une propriété booléen "occasion" et "usure".

On se doute bien que tu aura un traitement différentié en fonction de ces valeurs, mais après tout, c'est le cas pour la pluspart des valeur, sinon on aurait pas besoin de les stocker

Il faut d'abord partir simple

[cotmar]

Bonjour,

Je suis en train de l'implémenter, mais il me vient une autre question.
Comment va se traduire la transposition des classes en tables s'il vous plaît ? J'ai l'impression que ça va être assez compliqué.

Est-ce que je vais avoir des tables :
- Livre, Disque...
- Article,
- Produit, ProduitOccasion, ProduitNeuf.

Par avance merci.

Cordialement.
Marco.

[franck06]

Bonjour,

Je suis en train de l'implémenter, mais il me vient une autre question.
Comment va se traduire la transposition des classes en tables s'il vous plaît ? J'ai l'impression que ça va être assez compliqué.

Est-ce que je vais avoir des tables :
- Livre, Disque...
- Article,
- Produit, ProduitOccasion, ProduitNeuf.

Par avance merci.

Cordialement.
Marco.

ben y'a les 2 types de stratégies
une table par classe, ou une table pour tous les articles
si t'as qu'une table, tu mettras le type de l'article dans une colonne

[tchize_]

Je rajoute un détail non mentionné jusque là.

Alors qu'il est raisonnablement facile de changer une propriété d'un objet, par exemple pendant qu'on modifier une entrée dans une formulaire, via

objet.setOccasion(true)

par exemple,

il est beaucoup plus complexe, dans une structure de donnée, d'en changer la classe: il faut réinstancer et changer toutes les référence partout dans le code, et on en oublie toujours une quelque part

[joel.drigo]

il est beaucoup plus complexe, dans une structure de donnée, d'en changer la classe: il faut réinstancer et changer toutes les référence partout dans le code, et on en oublie toujours une quelque part

C'est vrai. D'un autre coté, il plutôt rare qu'un produit neuf devienne d'occasion sans qu'on l'ait vendu et racheté plus tard Donc je pense que l'instance de neuf peut être supprimée et une nouvelle instance d'occaz peut être créée. L'article lui ne change pas effectivement (L'ISBN tartempion restant tartempion qu'il soit neuf ou d'occaz).
Après je proposais de faire 2 classes dans l'idée que les propriétés pouvaient être complètement différentes : c'est sur que si les propriétés se résument à 2 booléens qui peuvent avoir un sens du reste pour les neufs et les occases, vaut mieux pas ne pas cse ompliquer la vie. Mais j'ai trop eu à gérer des modèles (fait par d'autres) de classes fourre-tout avec 36 propriétés qui n'avaient de sens que pour certains types (genre avec les 3/4 des accesseurs qui retourne null) pour ne pas indiquer la solution à plusieurs classes.

[tchize_]

C'est vrai. D'un autre coté, il plutôt rare qu'un produit neuf devienne d'occasion sans qu'on l'ait vendu et racheté plus tard

Mais l'erreur d'encodage n'est pas rare! De plus qu'on le fasse souvent ou pas n'est pas le problème. Le fait de devoir prévoir cette possibilité de changer le type d'une classe, c'est une problème de complexité à programme

[cotmar]

C'est vrai. D'un autre coté, il plutôt rare qu'un produit neuf devienne d'occasion sans qu'on l'ait vendu et racheté plus tard Donc je pense que l'instance de neuf peut être supprimée et une nouvelle instance d'occaz peut être créée. L'article lui ne change pas effectivement (L'ISBN tartempion restant tartempion qu'il soit neuf ou d'occaz).
Après je proposais de faire 2 classes dans l'idée que les propriétés pouvaient être complètement différentes : c'est sur que si les propriétés se résument à 2 booléens qui peuvent avoir un sens du reste pour les neufs et les occases, vaut mieux pas ne pas cse ompliquer la vie. Mais j'ai trop eu à gérer des modèles (fait par d'autres) de classes fourre-tout avec 36 propriétés qui n'avaient de sens que pour certains types (genre avec les 3/4 des accesseurs qui retourne null) pour ne pas indiquer la solution à plusieurs classes.

Bonjour et merci de toutes vos réponses,

En fait il y a bien une spécialisation de la part des classes Livre, Film et autres vis à vis de la classe abstraite "Article" avec des attributs différents entre chacune. D'où le sens de ma question, de savoir si il me faut faire autant de tables qu'il y a de tables ?

Car à mon niveau, je serais tenté de traduire les tables Livre, Film (...), Article, Produits et autres en autant de tables, mais ais-je raison ?

Un autre point, on devrait bien avoir :

public class Produit extends ProduitNeuf{...}

public class Produit extends ProduitOccasion{...}

Par avance merci,
Marco.

[cotmar]

Je vous donne mon diagramme de classes UML à l'état actuel d'avancement où je me trouve.

Je n'ai pas affiché l'ensemble des éléments des classes (en ce qui concerne les méthodes des classes filles en particulier).

A très bientôt et merci beaucoup.

Marco.