Discussion :

[avtonio]

Bonjour,

Je souhaite vous soumettre un probleme conceptuel qui m'agace ce matin !

Le voici:

Considerons un morceau d'application:

- couche métier :

• Classe Voiture
• Classe BMW extends Voiture

- couche graphique :

• Classe VoitureUI
• Classe BMWUI

Doit-on faire hériter la classe BMWUI de la classe VoitureUI ?

[®om]

Je dirais oui si la vue de la Voiture et de la BMW ont des choses en commun...
Si c'est totalement une autre vue, je dirais non

[avtonio]

Je dirais oui si la vue de la Voiture et de la BMW ont des choses en commun...

Merci.
Mais avec un héritage, n'y a-t-il pas un problème au niveau de la communication entre les 2 couches ?

ex:

héritage:
VoitureUI
+ setVoiture(Voiture voiture)

BMWUI extends VoitureUI
+ setBMW(BMW bmw)

La méthode héritée "setVoiture" ne semble pas à sa place dans BMWUI

Comment faites-vous ? composition ou héritage ?
et surtout pourquoi ?

Je trouve ce sujet tres interressant et je n'ai pas de certitude ...

[®om]

Merci.
Mais avec un héritage, n'y a-t-il pas un problème au niveau de la communication entre les 2 couches ?

ex:

héritage:
VoitureUI
+ setVoiture(Voiture voiture)

BMWUI extends VoitureUI
+ setBMW(BMW bmw)

La méthode héritée "setVoiture" ne semble pas à sa place dans BMWUI

Comment faites-vous ? composition ou héritage ?
et surtout pourquoi ?

Je trouve ce sujet tres interressant et je n'ai pas de certitude ...

Moi je ferai qqch comme ça:

Code :

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

1
2
3
4
5
6
public class VehiculeUI<V extends Voiture> {
    protected /* ou private, ça dépend */ V v;
    public void setVehicule(V v) {
        this.v = v;
    }
}

Code :

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

1
2
3
public class VoitureUI extends VehiculeUI<Voiture> {
    ...
}

Code :

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

1
2
3
public class BMWUI extends VehiculeUI<BMW> {
    ...
}

Mais après, si ton VoitureUI doit être capable d'afficher une BMW, c'est pas pratique, c'est vrai (il va afficher la bmw en tant que voiture, et non en tant que BMW)...

[spekal]

Généralement, à mon sens, il n'y a pas de relations directes entre le niveau métier et le niveau utilisateur, à part dans les systèmes de génération automatique d'applications inutilisables.

Autre est le niveau métier, autre est le niveau utilisateur.

Bien sûr, l'utilisateur est souvent une personne du métier, qui va avoir tendance à s'exprimer selon son métier (c'est même souhaitable). Mais cela ne veut pas dire grand chose sur l'aspect que cela prendra. Par exemple, dans ton cas, il se peut parfaitement que VoitureUI suffise pour BMWUI, et convienne pour toutes les sortes de voitures. A l'inverse il se peut que tu doives montrer des voitures selon d'autres découpes que celles du métier (selon une ambiance, un paysage, par exemple), et que cela te conduise à faire des BMWUIMontagne, BMWUICitadine, etc.

Donc, pour résumer, il faut étudier le niveau métier pour lui même, le niveau utilisateur pour lui même. C'est mon avis.

[xavlours]

Sinon, pour faire référence à ce qui existe, dans les look and feel, les correspondances Métier/Graphique sont stockées dans une map.

Tu peux donc utiliser une map qui contient :
Voiture -> VoitureUI
BMW -> BMWUI

Et tu utilises l'héritage de la manière que tu veux. A mon avis, ils n'ont pas fait ce choix pour rien (par exemple pour les boutons, il y a les mêmes héritages en métier/graphique, mais ils se cassent la tête à recenser AbstractButton, ToggleButton, radioButton, Button, CheckBox dans une map).

[NeptuS]

Ajouter une fonctionnalité à des classes regroupées sous 1 filliation commune ?
Choisir la classe dont on veut utiliser la méthode (set en l'occurence) en fonction du type de paramètres ?

Mais ça m'a tout l'air approprié au Design Pattern Visitor ça !!!

Tu devrais aller jeter 1 coup d'oeil sur le site du Gang of Four : le premier lien de Google : http://www.google.fr/search?hl=fr&q=...e+Google&meta=

Je ne suis pas du genre à doonner du code. En revanche, je peux t'assurer pour l'avoir utilisé, bien qu'un peu rude au départ, le DP Visitor est terriblement efficace et demande très peu de code.
En plus, il répond à ton problème.
N'hésite pas à reposter si tu n'y comprend rien

[avtonio]

merci pour vos réponses

Si je recapitule vos réponses pour le probleme que je me pose:

®om : tu es POUR l'heritage, avec utilisation des templates
Effectivement, l'usage des templates évite les bugs à l'execution.
Cepandant la lisibilité en est réduite.
On se retrouve avec VoitureUI.setVoiture(V v) et BMWUI.setVoiture(V.v) ...
Même si ça me plait pas trop, c'est peut etre bien la façon la plus commode!

spekal: je suis bien d'accord avec toi sur l'identité de l'UI.
Cependant ici, je considere les classes graphiques VoitureUI et BMWUI,
Sous entendu :voitureUI affiche tous les champs d'une Voiture et idem pour BMWUI. Quel lien entre ces 2 UI ?

xavlours: (joli pseudo )
Le principe d'externaliser le mapping me plait beaucoup, mais je trouve ça tres lourd car il ne suffit pas de dire: Voiture -> VoitureUI, il faut encore mapper chaque type de champs (primaire ou composite) ... en tout cas ça me plait !

NeptuS:
Le pattern Visitor ? soit. Mais je ne reconnais pas ici son application.
Je serai curieux de voir comment tu l'utilises.
(Je souhaite avant tout garder une independance totale de la couche métier.)

En tout cas merci d'avoir partagé votre experience.
Et je remarque que vous êtes globalement favorable à l'heritage, même si chacun l'implemente à sa façon.

Si d'autres personnes ont des idées je suis toujours prenneur !