Discussion :

[etiennegaloup]

Bonjour,

Je développe une appli qui permet de gérer des clients, fournisseurs, commandes, articles, etc.
Ces entites sont stockées dans une base de données
Suite à de nombreux messages laissé sur ce forum, je vais organiser cette application en couche: métier, dao, vue, et peut-être controller.

Je cherche à modeliser client et fournisseur.
Dans ma base de données, j'ai deux entités distinctes:
Table client:

CREATE TABLE T_CLIENT (
cli_id integer primary key, -- Identifiant du client Clé Primaire
cli_name varchar(32), -- Nom du client
cli_Adress varchar(32), -- Adresse du client
cli_cp varchar(5), -- Code Postal du client
cli_ville varchar(32), -- Ville du client
cli_tel varchar(20), -- Telephone du client
cli_fax varchar(20), -- Fax du client
);

Table fournisseur:

CREATE TABLE T_FOURNISSEUR (
fou_id integer primary key, -- Identifiant du fournisseur
fou_name varchar(32), -- Nom du fournisseur
fou_adress varchar(32), -- Adresse du fournisseur
fou_cp varchar(5), -- Code Postal du fournisseur
fou_ville varchar(32), -- Ville du fournisseurur
fou_tel varchar(20), -- Telephone du fournisseur
fou_fax varchar(20), -- Fax du fournisseur
);

Donc je pensais développer deux classes :
Classe Client:

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
public class Client {
    private int id;
    private String name;
    private String adress;
    private String cp;
    private String ville;
    private String telephone;
    private String fax;
 
    int getId(){
        return id;
    }
 
    String getName(){
        return name;
    }
    String getAdress(){
        return adress;
    }
 
    void setAdress(String adress){
        this.adress=adress;
    }
[..]
}

Classe Fournisseur:

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
public class Fournisseur {
    private int id;
    private String name;
    private String adress;
    private String cp;
    private String ville;
    private String telephone;
    private String fax;
 
    int getId(){
        return id;
    }
 
    String getName(){
        return name;
    }
    String getAdress(){
        return adress;
    }
 
    void setAdress(String adress){
        this.adress=adress;
    }
[..]
}

Donc les deux entités ont leur propriétés communes.
Et puis après tout, client et fournisseur sont des sociétés, certaines sont pour moi des clients et d'autres des fournisseurs.
J'ai pensé alors crée une sur-classe société et deux sous-classes client et fournisseur.
Qu'en pensez-vous ?

Mais quand on y regarde bien, client et fournisseur n'est pas vraiment une spécialisation de société, n'est-ce pas ? Donc, ce n'est pas vraiment une solution.

Mais c quand même dommage d'avoir des propriétés quasi toutes communes entre ces deux classes.

Ou devrai-je faire une classe identification. Et les classes Client et Fournisseur aurait chacune une propriété de type identification.

Ou je crée une classe Société et j'ajoute une propriété qui distingue si cette société est un client ou un fournisseur.

Qu'en pensez-vous ?
Comment modeliseriez-vous tout ça ?

Merci pour vos réponses.
++

[iohack]

Si tu tiens vraiment à les différencier ( dans le code ), je ferais comme suit ( peut-être y'a-t-il une meilleur solution ):
- je créérais une classe abstraite Identification regroupant tous les attribus communs à tes deux classes (ainsi que les méthodes getxxx et setxxx ).
- ensuite je dériverais cette superclasse pour client et fournisseur :

Code :

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

1
2
3
4
5
 
public class Client extends Identification{
}
public class Fournisseur extends Identification{
}

de cette manière il est possible de les différencier et on n'a pas eu le code à taper deux fois mais juste une seule.
Tu remarqueras que j'ai laissé les deux dernière classes vides, si des spécifications futures doivent être apporter à Client, il suffira de les rajouter. De la même manière si un attribut commun doit être mis en place, il sera rajouté dans Identification.

Enfin tout cela est théorique, rien ne t'empêche d'utiliser telle ou telle méthode. Il s'agit d'un problème de conception et non de langage. Fais ce qui pour toi est le plus simple au niveau de l'application finale ( performances, intégration évolution etc. ).

[etiennegaloup]

Salut,

Si tu tiens vraiment à les différencier

sinon je cree une classe société ? et un attribut différencie si c un client ou un fournisseur ?

je créérais une classe abstraite Identification regroupant tous les attributs

J'y ai pensé, mais Identification n'est pas une généralisation de client ou fournisseur, non ?

++

[adiGuba]

Salut,

J'y ai pensé, mais Identification n'est pas une généralisation de client ou fournisseur, non ?

Si c'est le nom qui te gène, tu peux utiliser "Contact" ou "Relation" (même si je trouve ca un peu bizarre).

L'idée c'est de ne pas avoir à réécrire deux fois le même code (ou un code similaire).
Bien sûr dans cette exemple le code est simple donc l'intérêt peut sembler minime.



Par exemple imagine que tu doives écrire une méthode qui permet d'imprimer un courrier avec l'entête de ton entreprise et l'adresse du fournisseur, suivi d'un texte (ou d'une objet plus complexe permettant de générer la page). Ceci pourrait servir à envoyer des commandes à tes fournisseurs par exemple...

Si tu fais ceci dans ta classe Fournisseur :

Code :

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

1
2
3
public void printCommande (String commande) {
    // ...
}

Et que tu as besoin de faire la même chose pour tes clients (pour leurs envoyer des factures), il faudra que tu recopies quasiment la même méthode dans la classe Client (le nom pourra être différent mais le code sera identique ou presque) :

Code :

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

1
2
3
public void printFacture (String facture) {
    // ...
}

Du coup tu te retrouves encore avec du code "en double"... et les évolutions futures prendront plus de temps...


Alors que si tu avais utilisé une classe parente (voir une interface) "Contact", il t'aurait suffit d'écrire une seule méthode dans Contact (eventuellement protected) :

Code :

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

protected void printMessage (String message)

Et tu pourrais jouter les méthode printFacture() et printCommande() dans tes classes filles Client et Fournisseur, qui se contente d'appeller la méthode printMessage :

Code :

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

1
2
3
4
5
public class Client extends ... {
          public void printFacture (String facture) {
                   printMessage(facture);
          }
}

Tu conserves ta logique sans réécrire le code...


Je te conseille même d'utiliser des interfaces, par exemple tu aurais une interface Contact :

Code :

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

1
2
3
4
5
6
7
public interface Contact {
 
	public int getId();
	public String getName();
	public String getAdress();
 
}

Et une classe abstraite qui en hérite :

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 abstract class AbstractContact implements Contact {
 
	private int id;
	private String name;
	private String adress;
 
	public AbstractContact(int id, String name, String adress) {
		this.id = id;
		this.name = name;
		this.adress = adress;
	}
 
	public int getId() {
		return this.id;
	}
 
	public String getName() {
		return this.name;
	}
 
	public String getAdress() {
		return this.adress;
	}
 
	protected void printMessage(String message) {
		// ...
	}
 
	// etc...
 
}

puis tes classes Client et Fournisseur...


La classe abstraite permet donc de regrouper le code commun de tes classes Clients et Fournisseurs, alors que l'interface se contente de décrire le comportement...

Ainsi tu pourrais éventuellement implémenter l'interface Contact pour autre chose que tes Client et Fournisseur sans forcément hériter de AbstractContact...


a++

[etiennegaloup]

L'idée c'est de ne pas avoir à réécrire deux fois le même code (ou un code similaire)

Oui je suis tout à fait d'accord avec ça.

La classe abstraite permet donc de regrouper le code commun de tes classes Clients et Fournisseurs, alors que l'interface se contente de décrire le comportement...

Et je suis toujours d'accord avec ça.

Si c'est le nom qui te gène, tu peux utiliser "Contact" ou "Relation" (même si je trouve ca un peu bizarre)

C pas tellement le nom qui me gêne, c plutôt le fait que normalement lorsque il y a sur-classe et sous-classe, c de la généralisation. Et là je ne trouvais pas tellement que cela était de la généralisation.
Et puis j'ai lu aussi qu'il fallait de préférence utiliser la composition plutôt que la généralisation, dans un livre d'UML.

Et que pensez-vous de faire une classe Identification ? Client et Founisseur aurait alors une propriété de type Identification.

++

[etiennegaloup]

Hello,

quelqu'un a-t-il une autre idée ?

Je dois aussi réaliser une classe qui permet de gérer des clients et fournisseurs, en ajouter, en supprimer.
Dois-je aussi développer une classe abstraite ManageSociety qui serait une sur-classe de ManageClient et ManageFournisseur ?

De même, je dois développer une interface graphique qui permet de saisir un nouveau client ou un nouveau fournisseur. Ou en rechercher un.
Dois-je développer une classe abstraite GuiAddSociety qui serait une sur-classe de GuiAddClient et de GuiAddFournisseur ?

Qu'en pensez-vous ?

Merci d'avance pour vos réponses.

++