Discussion :

[Mister Nono]

Voici le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
package dao.requete;


public class HibernateDaoFactory
{
   
    public static IDaoEngin getDaoEngin()
    {
        return new DaoEngin();
    }

  // suite du code ...
}

Le (pseudo) diagramme de classe suivant traduit-il la fonction getDaoEngin() ?

Code :

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

1
2
3
4

                         <<use>>       <<interface>>
HibernateDaoFactory -----------------> IDaoEngin <|-------DaoEngin

Merci.

[bruno_pages]

non, HibernateDaoFactory dépend de DaoEngin

HibernateDaoFactory ---<<use>>---> DaoEngin <|----- IDaoEngin

[Mister Nono]

non, HibernateDaoFactory dépend de DaoEngin

HibernateDaoFactory ---<<use>>---> DaoEngin <|----- IDaoEngin

Le type de relation que j'ai utilisé est bon.

Par contre, je ne suis pas d'accord avec toi : La fonction renvoi un IDaoEngin et en plus c'est DaoEngin qui implémente l'interface IDaoEngin et non le contraire comme tu l'as modélisé.

Dis-moi ce que tu en penses.

A+

[bruno_pages]

tu as raison, DaoEngin <|----- IDaoEngin est à l'envers

par contre le fait que le profile de l'opération retourne un IDaoEngin n'a aucune importance : getDaoEngin() créé un DaoEngin, donc
HibernateDaoFactory ---<<use>>---> DaoEngin

[Mister Nono]

tu as raison, DaoEngin <|----- IDaoEngin est à l'envers

par contre le fait que le profile de l'opération retourne un IDaoEngin n'a aucune importance : getDaoEngin() créé un DaoEngin, donc
HibernateDaoFactory ---<<use>>---> DaoEngin

Tu es sûr de cela ? Cela m'étonne car cela signifie que le jour ou le IDaoEngin retourné devient un DaoEngin2 au lieu du DaoEngin alors le modèle doit-être modifié. Pourtant un des buts de modéliser est d'obtenir une abstraction la plus grande possible par rapport au système.

A+

[bruno_pages]

un des buts de modéliser est d'obtenir une abstraction la plus grande possible par rapport au système.

de façon générale le but de la modélisation est de montrer ce qui est, pas d'induire le lecteur en erreur

Mais en fait il y a juste un quiproquo sur le but. Pour moi, lorsque tu fais un schéma montrant les dépendances de la classe HibernateDaoFactory celle-ci est une boite blanche, et donc tu décrits son implémentation (qui utilise DaoEngin). Toi tu voulais rester au niveau interface en considérant que ta classe est une boite noire, mais dans ce cas il ne faut pas faire cette dépendance, le fait que l'opération rendre un IDaoEngin suffit à lui même

[edit]
le 'bon' diagramme de classes boite noire contenant HibernateDaoFactory est un diagramme indiquant ses opérations publiques avec leur profile

un diagramme de classes boite blanche sur I]HibernateDaoFactory[/I] aura la dépendance vers DaoEngin car l'implémentation des opérations n'y étant pas visible l'utilisation de DaoEngin ne peut être déduite

par contre, si tu fais des diagrammes de composants et que l'un d'eux provide d'une façon ou d'une autre HibernateDaoFactory, alors il faudra que ce même composant require IDaoEngin
[/edit]

[ze_corsaire]

tu as raison, DaoEngin <|----- IDaoEngin est à l'envers

par contre le fait que le profile de l'opération retourne un IDaoEngin n'a aucune importance : getDaoEngin() créé un DaoEngin, donc
HibernateDaoFactory ---<<use>>---> DaoEngin

Ce n'est pas un petit HibernateDaoFactory ---<<instanciate>>---> DaoEngin dans ce cas ?

_______________

[bruno_pages]

Ce n'est pas un petit HibernateDaoFactory ---<<instanciate>>---> DaoEngin dans ce cas ?

si on ne regarde que le fait qu'il y est un new DaoEngin c'est oui

mais malgré le nom (factory) et ce new il est difficile de savoir si c'est effectivement le rôle premier de la classes car seule une opération à été dévoilée