Discussion :

[Ridounet]

Ohayo minna-kun!

Alors, je débute en Android. Je bricole plus qu'autre chose.

Je fais une app pour un resto/fast-food, permettant de commander à distance.
La gestion d'un panier classique, je pense pouvoir le mettre en place sans trop de problème.

Ici, dans le panier, je dois pouvoir contenir des produits, du style burger, boissons, etc.
Là où je bloque un peu, c'est au niveau des menus, qui sont aussi des produits, mais qui contiennent d'autres produits. Les menus doivent évidemment être aussi contenus dans le panier.

De plus, le prix d'un menu dépend du plat (la boisson ne change rien au prix)

Alors pour ce qui est du diagramme de classe, j'ai trouvé une solution (pas encore terminée mais bon): "Menu" qui hérite de "Produit", et un "Panier" contient une "Map<CategorieProduit, Integer>" (Integer = quantité)
=> Héritage et polymorphisme qui règle mon problème lol
Je vais sûrement modifier ça plus tard, c'était une solution provisoire à présenter

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class Produit {
 
    private long id;
    private String nom;
    private CategorieProduit categorie;
    private CategorieMenu categorieMenu;
    private double prix;
    private String imageReference;
    private long position;
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class Menu extends Produit {
 
    private static final float PRIX_SAUCE = 0.40f;
 
    private Produit boisson;
    private Produit plat;
    private Produit sauce;
 
    public Menu(Produit boisson, Produit plat) {
        setBoisson(boisson);
        setPlat(plat);
    }
 
    public Menu(Produit boisson, Produit plat, Produit sauce) {
        this(boisson, plat);
        setSauce(sauce);
    }
 
    // Getter & Setter
 
    public void setPrix () {
        if ((plat != null) && (boisson != null))
            setPrix(plat.getCategorieMenu().getPrix() + (sauce != null ? PRIX_SAUCE : 0f));
    }
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class Panier {
 
    private Map<CategorieProduit, Integer> map;
 
    public Panier() {
        map = new HashMap<>();
    }
 
    public void addProduit(Produit produit, int quantity) throws Exception {
        if (produit == null)
            throw new Exception();
 
        int initQuantity = 0;
        if (map.containsKey(produit.getCategorie())) {
            initQuantity = map.get(produit.getCategorie());
        }
        quantity += initQuantity;
        map.put(produit.getCategorie(), quantity);
    }
 
    public void addProduit(Menu menu, int quantity) throws Exception {
        if ((menu.getBoisson() == null) ||
                (menu.getPlat() == null))
            throw new Exception();
    }
 
}

Mon problème, c'est du côté base de données. Comment je dois transposer ça?

J'ai fait un mini schéma. Il manque des tas d'infos, je le sais, ce sont les relations qui m'intéressent ici.
Dans ce schéma, je n'ai mis que les produits, pas les menus... Le "type_menu" est associé aux simples produits.
Comme le prix d'un menu dépend du plat qui est choisi, alors je stocke un type directement dans le produit, type que je récupère pour fixer le prix d'un menu.

Voici le schéma


Voilà mon problème, je ne sais pas comment représenter ça côté DB. Des idées? ^^

J'ai encore un autre problème, mais que je présenterai plus tard peut-être, il est moins urgent x)

Dans tous les cas, merci d'avance à tous ceux qui essaieront de m'aider ^^

Ridounet

[grunk]

Menu ne peut pas hériter de produit. Tu es ici dans le cas d'une composition , pas d'un héritage.

Pour moi un menu est un produit que tu peux acheter comme n'importe quel autre. Ce qu'il y'a dedans n'as pas d'intérêt programmatiquement parlant.
Quand tu ajoute un burger à ton panier , tu ajoutes pas un steak, du pain , etc ... si ?
Quand tu met un PC dans ton panier sur ldlc , tu met un pc , pas ses composants.

Le seul cas qui pourrait nécessiter de gérer les menus comme des produits composés d'autres produits serait si tu as besoin de personnaliser les menu.

[Ridounet]

Merci beaucoup pour la réponse ^^

Effectivement, je n'ai pas été assez clair dans la description:
Un menu est justement personnalisable, l'utilisateur peut choisir n'importe quel burger ou autre plat possible, avec n'importe quelle boisson, et même n'importe quelle sauce. Du coup, si je devais stocker tous les menus possibles, je me retrouve devant plusieurs centaines de possibilités pour chaque menu ^^'

En comptant aussi le fait qu'il y ait plusieurs types de menus qui diffèrent sur base de critères comme leur taille (Medium et XL par exemple), mais aussi sur d'autres critères (un menu pour enfant ne laissant pas le choix de la boisson par exemple).

En conclusion, c'est la raison pour laquelle j'ai géré les Menu via un héritage: Car ce sont AUSSI des produits, mais qui contiennent d'autres produits, qui sont variables pour un même menu, dans la même commande... J'avais prévenu que c'était tordu =p

[joel.drigo]

Salut,

Pourquoi ne pas simplement dire qu'un produit a 2 tarifs : un normal (hors menu) et un "en menu". Ensuite, une commande (un panier) peut se gérer par association avec un attribut qui dit que le produit est dans un menu ou pas (un lien sur le type de menu s'il faut pouvoir afficher le type de menu). S'il y'a plusieurs tarifs différents selon les types de menu, au lieu de 2 propriétés sur le menu, on a une association produit-menu avec un attribut tarif pour ce menu (avec un menu spécial qui désigne le menu "hors menu", filtré dans les listes de menus sélectionnables).

[Ridounet]

J'ai pensé à une solution du genre "2 tarifs", c'est l'idée du "type_menu" dans la DB. Une fois un menu composé, on recherche le "type_menu" du produit "plat" et on retrouve le prix.

Mais maintenant que tu as posé la question, j'y réfléchis plus en détails et je me rends compte que ce n'est pas bon -_-'
Pour un produit donné (la table est fixe et non variable), il y a un "type_menu" alors qu'un même produit peut-être dans plusieurs types de menus (le XL étant évidemment plus cher que le Medium par exemple)... Donc avec ma solution, on ne récupère qu'un prix, alors qu'un même plat peut donner plusieurs prix de menus différents... ><'

Vraiment casse-tête ce machin-là...


D'un autre côté, je crois que je suis pas clair depuis le début ^^' je m'en excuse.

Voici la solution à laquelle j'avais pensé côté Java (qu'il faudra donc adapter):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class Produit {
 
    private long id;
    private String nom;
    private CategorieProduit categorie;
    private CategorieMenu categorieMenu;
    private double prix;
    private String imageReference;
    private long position;
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public enum CategorieProduit {
 
    MENU(0, "Menu"),
    BURGER(1, "Burger"),
    // ...
    DESSERT_MILKSHAKE(11, "Milkshake"),
    DESSERT_DOUCEUR(12, "Douceur");
 
    private int id;
    private String label;
 
    CategorieProduit(int id, String label) {
        this.id = id;
        this.label = label;
    }
 
	// Getter & Setter
 
    public static CategorieProduit valueOf(int id) {
        switch (id) {
            case 0: return CategorieProduit.MENU;
            case 1: return CategorieProduit.BURGER;
			// ...
            case 11: return CategorieProduit.DESSERT_MILKSHAKE;
            default: return CategorieProduit.DESSERT_DOUCEUR;
        }
    }
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public enum CategorieMenu {
 
    BURGER_SMALL("Burger", 0, 1.50),
    BURGER_MIDDLE("Burger", 1, 1.70),
    BURGER_HIGH("Burger", 2, 1.90),
	// ...
    OTHER("Autre", 8, 0);
 
    private String label;
    private int id;
    private double prix;
 
    private CategorieMenu(String label, int id, double prix) {
        this.label = label;
        this.id = id;
        this.prix = prix;
    }
 
	// Getter & Setter
 
    public static CategorieMenu valueOf(int id) {
        switch (id) {
            case 0: return BURGER_SMALL;
            case 1: return BURGER_MIDDLE;
            case 2: return BURGER_HIGH;
			// ...
            default: return OTHER;
        }
    }
 
}

=> "CategorieMenu" = "type_menu" dans la DB
Cet enum servait à dire que CE produit vaut autant une fois en menu (mais du coup, faut le modifier...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class Menu extends Produit {
 
    private static final float PRIX_SAUCE = 0.40f;
 
    private Produit boisson;
    private Produit plat;
    private Produit sauce;
 
    public Menu(Produit boisson, Produit plat) {
        setBoisson(boisson);
        setPlat(plat);
    }
 
    public Menu(Produit boisson, Produit plat, Produit sauce) {
        this(boisson, plat);
        setSauce(sauce);
    }
 
    // Getter & Setter
 
    public void setPrix () {
        if ((plat != null) && (boisson != null))
            setPrix(plat.getCategorieMenu().getPrix() + (sauce != null ? PRIX_SAUCE : 0f));
    }
 
}

Voilà, avec les catégories, ça paraît plus clair je pense.
Je précise que je ne tiens pas spécialement à garder CE code-là, je veux dire que je suis prêt à modifier le code Java pour faciliter la structure de la DB.
Pour ce qui est du panier, je dois encore le travailler côté code de toute façon, mais dans tous les cas il contiendra une liste (List, Set ou Map, encore à voir).

Je retravaille le côté code maintenant, et je reviens vers vous avec une nouvelle solution (j'espère), en attendant, je bloque toujours côté DB donc si des idées, n'hésitez pas! ^^


Désolé pour le tout, et merci d'essayer de m'aider ^^'

[Ridounet]

Pour être plus clair, voici un exemple:

On a un burger A, et un burger B
On a un menu Medium, et un menu XL

Le menu Medium coûterait 5€ si on choisissait le burger A, mais 6€ si on choisissait le burger B
Le menu XL coûterait 6€ si on choisissait le burger A, mais 7€ si on choisissait le burger B.

Donc le prix dépend du type de menu et du plat sélectionné
Le prix NE DÉPEND PAS de la boisson ou sauce choisies.


L'idée que j'avais avec la catégorie menu, c'est que comme plusieurs plats ont le même prix une fois en menu (quel que soit le menu, ils ont exactement le même prix à chaque fois), je pensais les regrouper en catégorie, ce qui me simplifiait la vie plutôt que de stocker une info pour CHAQUE produit.

[joel.drigo]

En gros, le prix du type de menu dépend du burger : avec ma proposition, ça veut dire juste que le prix du burger pour chaque type de menu est différent, et le prix des boissons, frites, sauces, etc... vaut 0 pour tous les types de menu, sauf le type "hors menu". C'est exactement ce qu'on voit sur les facturettes d'un fast-food connu : si on prend un menu truc, on voit le burger à un prix et le reste à 0.

[grunk]

Code :

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

1
2
3
4
5
6
7
8
public class Menu extends Produit {
 
    private static final float PRIX_SAUCE = 0.40f;
 
    private Produit boisson;
    private Produit plat;
    private Produit sauce;
}

Ca me brule toujours autant les yeux :'( et du coup je me répète , héritage != composition

Et je rejoins joel sur sa solution.

[nicroman]

Oui je rejoins les autres un Menu *n'est pas* un Produit.

Pour pouvoir faire de l'héritage il faut se poser la question suivante:
* Est-ce qu'à chaque fois que j'ai besoin d'un produit je peux utiliser un menu ?

La réponse est obligatoirement non ici, puisqu'un menu contient des produits (et ne peut pas contenir d'autre "produits").
Il serait possible d'avoir un élément "achetable" dont héritent à la fois Produit et Menu, mais pas Menu de Produit.

Maintenant, dans notre cas présent, il y a deux choses:
* La liste de tous les produits demandés (j'imagine pour la réalisation)
* La liste de tous les prix payés (pour la facturation).

Je pense qu'il faut bien séparer les deux... D'autant que seule la facturation a besoin de connaitre la notion de "Menu".

Voici comment j'organiserai les trucs.

Object = type d'objet + nom + prix (par défaut) <= les objets vendus
Offre = "nom de l'offre" (par exemple menu XL). <= les menus
Contenu_Offre = Offre + Type d'objet + prix <= permet de définir un prix global pour un certain type d'objet dans cette offre. (le prix peut être null histoire de dire qu'on en a pas).
Prix_Offre = Offre + Objet + prix <= permet de définir un prix pour un certain objet dans cette offre.
Type d'objet = Burger, Boisson, .... <= permet de grouper les objets entre eux.

Ainsi dans ton exemple on aurait (je ne met pas les identifiants qui permettront les Foreign Key... mais quand je dis Toto contient Tata, c'est qu'il contient juste un LONG qui est une foreign key sur l'identifiant de Tata):

Type d'objet: Burger, Boisson, Sauce
Objet: (Burger,A,5), (Burger,B,6), (Boisson,A,1), (Boisson B,1.5), (Sauce,A,0.5), (Sauce,B,1)
Offre: Menu, MenuXL
Contenu_Offre : (Menu,Burger,null),(Menu,Boisson,1),(Menu,Sauce,0), (Menu,Burger,null),(Menu,Boisson,1.5),(Menu,Sauce,0)
Prix_Offre : (BurgerA,Menu,3),(BurgerA,MenuXL,4),(BurgerB,Menu,4),(BurgerB,MenuXL,5)


Maintenant, la gestion du panier... dans un panier on veut coller des objets et des offres. Il va falloir donc aggréger les deux d'une manière ou d'une autre.
Ainsi on aurait par exemple:
Panier: <= le panier lui-même
Panier_Offres: Offre <= les "offres" contenues dans le panier
Panier_Objets: Objet + Prix + Panier_Offre <= les objets contenus dans le panier (et éventuellement, l'offre du panier à laquelle ils sont associés).

Quand on rajoute un objet dans le panier... disons une "BoissonB", il n'y a pas d'offre, donc on va juste créer une entrée dans Panier_Objets en regardant le prix dans Objet: (BoissonB,1.5,null)
Quand on rajoute un menu dans le panier... disons "Menu" avec BurgerA, BoissonB et SauceB, on va regarder les prix dans Prix_Offre d'abord, puis dans Contenu_Offre ensuite (et si nulle part on prendra le prix de Objet lui même).
Ainsi on va rajouter dans Panier_Offres (1,Menu) et dans Panier_Objets: (BurgerA,3,1), (BoissonB,1,1), (SauceB,0,1)
ou alors avec un menu XL: dans Panier_Offres (1,MenuXL) et dans Panier_Objets: (BurgerA,4,1), (BoissonB,1.5,1), (SauceB,0,1)

Pour avoir la liste des objets & offre et leurs tarifs: on fera deux listes:
La liste des Panier_Objets dont le "panier_offre" est null avec le nom de l'objet et le prix. (Ici: BoissonB, 1.5)
La liste des Panier_Objets groupé sur "panier_offre" dont le panier_offre n'est pas null avec le nom de l'offre, et la somme des prix. Ici: (Menu, 4) ou (MenuXL,5.5)
=> et voilà... on aura les deux avec des prix différent.

Changer de burger dans le menu change bien le prix global.
Changer de sauce non. Changer de boisson non plus.


Dire que d'habitude je facture ça 100€ de l'heure minimum !

[Ridounet]

Purée, vive l'expérience... C'est très loin de ce que j'avais proposé au départ ><' Faut vraiment que j'améliore mes compétences d'analyse...

Bref, désolé pour ma longue absence, ça fait presque un mois que la solution a été proposée, et je ne réponds que maintenant... J'étais assez chargé depuis, désolé ^^'

Concernant la solution proposée, je l'aime bien, ça paraît beaucoup plus clair comme ça. Voici le schéma que j'ai fait sur base de ça, ça correspond bien à ta solution?




Avant de voir ta solution Nicroman, j'ai retravaillé de mon côté après avoir lu la proposition de joel.drigo. Dans tous les cas, je prends ta solution, mais pour mon "apprentissage", j'aimerais savoir ce que vous en pensez! Critiquez, Critiquez! lol
Si j'ai bien compris ta proposition joel, voici ce que j'ai pondu:



Modèle:
Un "produit" a une "categorie_produit"
Il y a des "menu" (Menu, MenuXL, etc).
Une table de jointure entre "produit" et "menu" qui nous donne un "type_menu" avec un prix.
=> L'idée en mettant le prix dans une catégorie à part, c'est de changer les prix à plusieurs produits en même temps. "Le produit est de cette gamme donc tel prix, pareil pour tous les produits de cette gamme" -> Si changement de prix pour la gamme, tous sont modifiés.

Panier:
Un "produit_panier" contient un "produit" ("plat_fk") présent dans tous les cas. Je dois changer le nom parce que ce champ peut-être autre chose qu'un plat (une boisson ou autre). Ce champ est obligatoire.
Un "produit_panier" contient aussi un booléen qui nous indique s'il s'agit d'un "menu" ou non. Si oui, Foreign Key vers le menu en question, et avec le "plat_fk" et le "menu_fk", on retrouve le "type_menu" qui nous indique le prix final de ce "produit" lorsqu'il est dans ce "menu".
Une fois le "menu" identifié, on a un champ "boisson_fk" et "sauce_fk" qui référence d'autres "produit".
Une table "panier".
Une table "ligne_panier" qui référence le "panier" auquel elle appartient, et un "produit_panier". Avec en plus une quantité de ce "produit_panier", et un "prix" que l'on reprend de:
- "produit.prix_base" si non "menu"
- "type_menu.prix" si "menu", grâce aux Foreign Key "produit_panier.plat_fk" et "produit_panier.menu_fk"


Cette solution me plaît aussi, parce qu'elle est bien compréhensible je pense. Ce qui me dérange par contre c'est que dans "produit_panier" on ait 3 champs qui dépendent de la valeur du booléen "is_menu", et que les valeurs de ces champs-là doivent être gérées programmatiquement... S'il s'agit d'un menu, "plat_fk" est obligatoirement un plat, et pas n'importe quel produit. Ce genre de choses ne me plaît pas trop (même si c'est très courant dans certains cas...).

Dans tous les cas je pars sur la solution de Nicroman, qui est plus clair je trouve.

Quant au souci de l'héritage entre "Produit" et "Menu", me suis au final dit que c'était peut-être bien débile lol si j'ai un "Menu" qui contient des "Produit", le "Menu" peut aussi contenir d'autres "Menu" etc. Bref, vu comme ça, j'aime moins lol Je garde l'idée de Nicroman d'avoir une interface dont hériteraient "Menu" et "Produit", ça sera beaucoup plus propre comme ça...



Dans tous les cas, je vous remercie tous les 3 pour vos conseils ^^ Je reviendrais vous harceler pour le diagramme de classe =p Merci pour tout ^^


Ridounet