Discussion :

[Gibou]

Bonjour,

J'ai encore quelques soucis avec le principe d'interfaces et visiblement, c'est par là qu'il faut que je m'oriente mais j'aimerais votre(vos) avis.

Voilà, j'ai un projet en .NET et on m'a demandé de rassembler dans une dll les éléments qui pourraient être commun à d'autres projets du même type comme la gestion des communications SQL, les utilisateurs, la création de treeview, etc...

Jusque là, pas de problème mais je me heurte à un problème au niveau de la gestion des utilisateurs. Dans la dll, j'ai ça :

classe GContact qui hérite de GUser
(G pour Généric)

Un user a juste u login/pwd
Un contact est un user avec un nom, prénom, job, tel, statut, etc... On les différencie car ils n'ont pas du tout les mêmes droits.

Ensuite dans le projet dans lequel j'inclus la dll, j'ai ça :

classe Contact qui hérite de GContact et classe User qui hérite de GUser.

Question : comment fais-je le lien entre Contact et User ? L'héritage se fait au niveau -1, entre GContact et GUser mais on ne voit donc pas les ajouts des classes filles Contact et User. Or, l'héritage multiple n'existe pas en .net, il faut interfacer.

Mais je ne parviens pas à trouver le bon raisonnement. Faut il hériter de GUser et implémenter une interface IUser ? Le contraire ?

Si quelqu'un pouvait m'aiguiller :-)

Merci et bonne journée

[pseudocode]

Question : comment fais-je le lien entre Contact et User ? L'héritage se fait au niveau -1, entre GContact et GUser mais on ne voit donc pas les ajouts des classes filles Contact et User. Or, l'héritage multiple n'existe pas en .net, il faut interfacer.

"on ne voit pas" ? C'est qui le "on" ?

[Gibou]

Le développeur, d'un point de vue code donc.
comme illustré sur ce petit dessin fait rapidement:



Mon problème est la visibilité de Contact à User (mon super oeil rouge, en haut).

[pseudocode]

Le développeur, d'un point de vue code donc.
comme illustré sur ce petit dessin fait rapidement:



Mon problème est la visibilité de Contact à User (mon super oeil rouge, en haut).

C'est le développeur (coté Projet) qui crée les classes Contact et User. Donc il n'y a pas de problème de visibilité de ce coté là.

J'avoue que je ne comprends pas trop le problème.

[Gibou]

Non mais je parle d'accessibilité là.
Je ne peux pas accéder aux méthodes de User depuis Contact.

[pseudocode]

Non mais je parle d'accessibilité là.
Je ne peux pas accéder aux méthodes de User depuis Contact.

Si ta classe "Contact" connait la définition de la classe "User", je ne vois pas pourquoi elle ne pourrait pas accéder a ses méthodes.

Si ta classe "Contact" connait seulement la définition de la classe mère "GUser" alors elle ne peut pas accéder aux méthodes spécifiques de la classe fille "User". C'est une règle de base dans un langage typé statique : on ne connait que les méthodes déclarées par le type.

[Gibou]

Oui, je sais bien ça.

C'est pourquoi je demande comment je pourrais réorganiser tout ça de manière à ce que :

User puisse accéder uniquement aux méthodes de GUser
GContact puisse accéder uniquement aux méthodes de GUser
Contact puisse accéder aux méthodes de User, GContact et GUser

Certes un moyen simple de faire une chaîne d'héritage descendante comme celle-ci :

Contact hérite de User qui hérite de GContact qui hérite de GUser.

Mais User qui hérite de GContact n'a pas de sens car un user n'a pas de nom, prénom par exemple.

Ce que je demande c'est un refactor de mon organisation car je ne parviens pas à trouver les bonnes règles d'hérite voire d'interfaçage pour avoir les bons accès :-)

[pseudocode]

Ce que je demande c'est un refactor de mon organisation car je ne parviens pas à trouver les bonnes règles d'hérite voire d'interfaçage pour avoir les bons accès :-)

Si tu n'as pas le droit à l'héritage multiple, tu peux utiliser le pattern décorateur pour rajouter le comportement de "contact" à une classe héritée de "user".

Code java :

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
32
33
34
35
36
 
interface IUser {
	String getLogin();
	String getPassword();
}
interface IContact {
	String getName();
}
 
// ---------------------------------------------------------------
 
class GUser implements IUser {
	@Override
	public String getLogin() { return "login"; }
	@Override
	public String getPassword() { return "password"; }
}
 
class GContact extends GUser implements IContact {
	@Override
	public String getName() { return "name"; }
}
 
// ---------------------------------------------------------------
 
class User extends GUser {
	public String getSpecificUserData() { return "userdata"; }
}
 
class Contact extends User implements IContact {
	GContact decoratedContact = new GContact();
	@Override
	public String getName() { return decoratedContact.getName(); }
 
	public String getSpecificContactInfo() { return "contactinfo"; }
}

[Gibou]

aaaaah, pas con, je le connaissais pas celui-ci

Merci beaucoup de ta patience !