Type d'un objet = forcément sa Classe ?

Bonjour,
J'ai une question portant sur la conception objet en général : pour faire simple je vais prendre un exemple : une usine produit différent produits. On veut gérer chaque produit individuellement, et on veut savoir quel type de produit l'usine PEUT produire (c'est à dire si elle est équipée pour, pas si elle en déjà produit).
Voilà une première façon de modéliser cela avec un diagramme de classe :
http://looking.dwarf.free.fr/images/bd.png
Chaque instance d'Usine aura alors un tableau de TypeProduit contenant tous les types de produit qu'elle peut produire.
Mais voilà mon problème ce situe dans la relation entre TypeProduit et Produit. Cela me semble bizarre d'avoir une Classe TypeProduit "séparée" de Produit alors qu'un Produit est l'instanciation d'un certain type de produit.

D'où une deuxième solution : on introduit dans le diagramme UML la classe de Produit, appelée ClasseProduit (notons que ClasseProduit sera la classe mère de nombreuses autres classes comme : ClasseAspirateur, ClasseMixeur, ClasseTV). Un aspirateur donné de numéro de série 4653 sera donc aussi un produit. Voilà le diagramme des classes correspondant :
http://looking.dwarf.free.fr/images/bd3.PNG
Chaque instance d'Usine aura alors un tableau de Class contenant toutes les classes de produit qu'elle peut produire.

La deuxième solution me semble plus proche de la POO (on utilise les classes comme un moule pour instance, mais aussi comme un type d'instance), mais est plus lourde (il faut faire une nouvelle classe par type de produit). Alors laquelle des deux trouve grâce auprès de vous ?

Merci d'avance pour toutes les précisions que vous pourrez apporter sur ces deux possibilités.

P.S. : la cardinalité de Produire dans le diagramme 2 est 1..* des deux côtés. De plus dans le diagramme 2 on a ajouté la relation "instance de", qui n'existe pas. Mais comment représenter en UML une relation concernant la classe et pas une de ses instances ?
P.P.S. : Usine aura alors un tableau de Class contenant normalement QUE des classes dont les instances seront des produits (c'est à dire que dans la hiérarchie des classes-mères, on tombera forcément sur ClasseProduit comme superclasse à un moment donné).
Mais comment s'assurer de cela ? Pourrait-on spécialiser le type Class ?

Bonjour,
j'ai l'impression que tu mélanges classes et objets. Il n'existe pas de relation de type "instance de" entre classes, un objet est instance d'une classe, mais une classe n'est pas instance d'une autre classe.
Pour en revenir à ton problème de produits, tu as trois types d'objets (ou classes) : une classe Usine, une classe TypeProduit, une classe Produit.
La classe Usine est en relation avec la classe TypeProduit et Produit (en effet, une usine fabrique différents produits de différents types). De même, la classe TypeProduit est en relation avec la classe Produit (un produit est d'un type bien défini).

Citation:

---

Envoyé par Xitog

Mais voilà mon problème ce situe dans la relation entre TypeProduit et Produit. Cela me semble bizarre d'avoir une Classe TypeProduit "séparée" de Produit alors qu'un Produit est l'instanciation d'un certain type de produit.?

---

Produit est une classe, TypeProduit une autre, en aucun cas un produit n'est une instance d'un type de produit : la classe Produit dispose d'un attribut de type TypePoduit.
En conclusion, ton premier diagramme UML est selon moi conforme à une modélisation correcte de ton problème.

Merci de t'intéresser à mon problème.

Mais pourtant, dans l'exemple bien célèbre de la classe Mammifère et de ses classes filles (par exemple : Eléphant et Baleine). Toutes les baleines seront des instances de Baleine et les éléphants des instances d'Elephant. Et la réponse quel est le type de cet animal X (ici type = espèce) on aura juste à prendre la classe de l'objet X (qui sera dans notre exemple soit Elephant soit Baleine en considérant que Mammifère est une classe abstraite).

Ici le type est la classe. Alors pourquoi un aspirateur ne pourrait avoir comme type la classe Aspirateur qui aurait comme classe mère Produit ?

Et on pourrait imaginer une classe Zoo (comme mon Usine) qui contiendrait une liste de classes d'animaux "acceptables" (c'est à dire qu'ils ont les cages pour les accepter). On aurait au lieu de "Produire" une relation "Accepter" entre une instance de Zoo est des classes filles de mammifères.

P.S. : oui mon diagramme UML n°2 peut induire en erreur. Je voulais juste en représentant de façon différente Produit et ClasseProduit pour montrer une relation concernant la classe de Produit et pas ses instances, c'est à dire que Usine aura un tableau de Class (et comment représenter cela en UML ?). Mais en fait les deux dans un bon diagramme UML, fusionneraient en une seule classe Produit. En fait, est-il bien d'un point de vue POO de manipuler des classes plutôt que des instances ?

Citation:

---

mais une classe n'est pas instance d'une autre classe.

---

P.P.S : une classe est bien une instance de la classe Class non ?

Citation:

---

Envoyé par Xitog

Mais pourtant, dans l'exemple bien célèbre de la classe Mammifère et de ses classes filles (par exemple : Eléphant et Baleine). Toutes les baleines seront des instances de Baleine et les éléphants des instances d'Elephant. Et la réponse quel est le type de cet animal X (ici type = espèce) on aura juste à prendre la classe de l'objet X (qui sera dans notre exemple soit Elephant soit Baleine en considérant que Mammifère est une classe abstraite).

---

Tout à fait d'accord, mais je ne vois pas bien le rapport avec mon post ou même ton post initial. Là tu parles d'héritage entre classes, une classe mère Mammifère abstraite et deux classes filles concrètes. Dans ton post initial, il s'agit plus de composition entre classes.

Citation:

---

Envoyé par Xitog

Ici le type est la classe. Alors pourquoi un aspirateur ne pourrait avoir comme type la classe Aspirateur qui aurait comme classe mère Produit ?

---

Type=Classe, nous sommes d'accord. Pour ce qui est du type Aspirateur, on peut effectivement le voir comme une classe fille de Produit.
Resta à définir précisément ce qui se cache derrière la classe TypeProduit.. Ce pourrait être une classe permettant de catégoriser des Produits : on pourrait avoir des types de produit Alimentaire, Outillage, ElectroMenager, ... Un TypeProduit n'a pas de prix, pas de quantité en stock, ..., contrairement à un Produit par exemple. Quand un produit est instancié, sa propriété TypeProduit est fixée pour savoir s'il s'agit d'un produit Alimentaire, Outillage, etc.

Citation:

---

Envoyé par Xitog

une classe est bien une instance de la classe Class non ?

---

Ce que tu obtiens en faisant .class, c'est un objet de type Class, et non une classe. La seule façon de produire une classe c'est d'écrire dans un source Java :

Code:

---

1 2 3 4

class Exemple { ... }

---

et de compiler ce source. Une classe est une description de type, elle ne "vit" pas. Seule une instance de classe (un objet) naît, vit et meurt.

Citation:

---

Ce que tu obtiens en faisant .class, c'est un objet de type Class, et non une classe. La seule façon de produire une classe c'est d'écrire dans un source Java :
Code:

class Exemple {
...
}

et de compiler ce source. Une classe est une description de type, elle ne "vit" pas. Seule une instance de classe (un objet) naît, vit et meurt.

---

En fait mes questions proviennent d'une exposition intensive à Ruby. Peut être ai-je été pervertit par ce petit joyau (facile) de langage mais en Ruby, la classe est un objet comme un autre.
Ex :

Code:

---

1 2 3 4 5 6

A = Class.new # On définit une nouvelle instance de la classe Class qui est une classe def A.pipo() # On ajoute une méthode à A puts 'hello world' end A.pipo # Affiche hello world

---

En Java il me semble bien que la définition d'une classe est quelque chose de beaucoup plus statique, mais dans ces langages dynamiques, les classes me semblent beaucoup plus "simple" et accessible dans leur manipulation : en effet on peut, comme en Java faire un

Code:

---

1 2 3 4

class A # Méthodes & Attributs end

---

Ou manipuler un objet classe dynamiquement pour constituer sa classe.
Les classes, dans ces langages ont donc bien une vie à part entière.

Un dernier truc : en Java, il n'y a pas de méthodes ou d'attributs singleton, c'est à dire ne s'appliquant qu'à une instance particulière de classe. Ainsi avec un objet Class en Java (obtenu par getClass) on ne pourra jamais faire :
monObjetClasse.attribut_statique
ou
monObjetClasse.fonction_statique
Alors qu"en Ruby on peut le faire. (accès avec l'attribut class).

Ton approche ressemble plutôt à la conception d'une base de données.

Pour répondre à ton problème, voici les classes :

Code:

---

1 2 3 4 5 6 7 8 9

classe abstraite Produit : classe de base de tous les produits classe Usine attribut typesProduitsFabriques : Tableau des classes de produits fabiques par l'usine methode fabriqueProduit(typeProduit : classe Produit) renvoie objet Produit classe Aspirateur hérite de produit classe Televiseur hérite de produit classe LecteurDVD hérite de produit

---

Code:

---

1 2 3 4 5

methode fabriqueProduit(typeProduitDemande : classe Produit) renvoie objet Produit si typeProduit dans typesProduitsFabriques alors renvoyer new typeProduitDemande sinon erreur('Cette usine ne fabrique pas de ' + typeProduitDemande);

---

Pour dire que l'usine A peut produire des teles et lecteurs dvd, tu dois créer une instance d'usine et renseigner son attribut typesProduitsFabriques :

Code:

---

1 2	objet usineA = new Usine usineA.typesProduitsFabriques = [Televiseur, LecteurDVD]

---

Et pour obtenir un objet televiseur de l'usine A :

Code:

---

Televiseur tv = usineA.fabriqueProduit(Televiseur)

---

Bloon

salut

Je pense qu'il faut conceptuellement séparer le "type de produit"
( aspirateur, TV, ...) du type informatique qui dans un langage OO correspont à la classe utilisée pour representer le concept du monde réel.

Quand au choix de les confondre, à mon humble avis c'est un détail
d'implémentation qui en fonction du langage dictera ton choix.