[POO]Classe ou pas classe

Version imprimable

24/05/2007, 11h22
loverdose

[POO]Classe ou pas classe

Bonjour ! :)

J'ai un petit problème d'architecture que je voudrais vous soumettre. Je pense qu'il est tout simple mais j'arrive pas à me décider.

J'ai deux classes Employé et Ouvrier qui ont exactement les memes comportements et les memes propriétés, la seule différence étant leur type (l'un Ouvrier et l'autre Employé).

Je suis en fait en train d'hésiter entre deux facons différentes pour essayer d'implémenter ces classes.

1- Soit je crée une classe Personne de laquelle hériteront les classes Employé et Ouvrier.

2- Soit je crée une classe Personne avec une propriété en plus qui s'appelera TypePersonne et qui pourra contenir [Employé, Ouvrier], pour pouvoir distinguer une personne Employé et une personne Ouvrier.

Quelle approche serait la mieux d'après vous? :roll:
24/05/2007, 11h40
Diablo_22

je pencherais pour

1- Soit je crée une classe Personne de laquelle hériteront les classes Employé et Ouvrier.

c'est la meme chose que pour voiture

ta une classe Voiture de laquelle hériteront les classes Camions, Berline, Break,..etc
24/05/2007, 11h43
Nikk0

Salut,

+1 pour la solution d'héritage ..
créer une personne et ensuite tu fais hériter ouvrier et employé
24/05/2007, 12h16
guis14

+1 aussi pour l'heritage ...
24/05/2007, 12h25
chtig

Humm... Pour le coup je suis moyennement d'accord avec l'idée de l'héritage.

Pour moi, ce qui permet de faire le choix entre les deux solutions, c'est vraiment de savoir si un Employe et un Ouvrier ont des différences autres que celles d'être un Employe et un Ouvrier, comme d'autres attributs(propriétés) ou d'autres méthodes(capacités).

Or dans la présentation que tu fais, la seule différence est cette notion de nature. On n'est donc pas du tout dans le cas de Voiture ...

Donc pour moi, ce serait un attribut type de Personne. Si on regarde l'API standard, on a plein de cas où cette implémentation avec un attribut type est mise en oeuvre (un exemple parmi d'autres : File, on a pas de classe Directory etc ...).

C'est quand même beaucoup plus pratique de pouvoir avoir des méthodes isOuvrier et isEmploye que de faire des tests instanceof ....
24/05/2007, 13h28
Nesmontou

Salut, je suis d'accord avec chtig ; petit exemple pour illustré : j'ai un ouvrier - Bob - que l'on définit

Code:

Ouvrier bob = new Ouvrier();

Et Bob travaille super bien, du coup il devient employé... Ca n'est pas trivial avec de l'héritage.

D'où mon soutien à chtig ;)

PS : c'est vrai que s'il n'y a pas d'évolution possible pour qu'un ouvrier devienne employé, mon exemple tombe à l'eau :cry:
24/05/2007, 14h38
elmor

+1 pour un attribut.

Par contre vu que je ne vois pas la différence entre un employé et un ouvrier.
Il faut peut-être uniquement une classe employés et ajouter plusieurs type d'employés: Ouvrier, Secrétaire, Ingénieur ...

A moins qu'il y ait des personnes qui ne soient pas employés...

Dans ce cas, il vaut mieux créer un classe personne avec une sous classe employés (Un employés il est payé :D ) et chaque employés à un type.

Pourquoi ne pas utiliser les interfaces?

Code:

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
37
38
39
40
41
public Interface Ouvrier {
    + set/get
}
 
public Interface Employe {
    + set/get
}
 
public class Personne implements Ouvrier, Employe {
    - attributs d'instances
    + set/get
     public Employe evolution() {
         if (this instanceof Employe) {
             throw new EvolutionImpossibleException();
         }
         Employe employe = new Personne();
         employe.setX(this.getX());
         ....
         return employe;
     }
 
     public Ouvrier regression() {
         if (this instanceof Ouvrier) {
             throw new RegressionImpossibleException();
         }
         Ouvrier ouvrier = new Personne();
         ouvrier.setX(this.getX());
         ....
         return ouvrier;
     }
}
 
public class Test {
    public void test() {
        Ouvrier ouvrier = new Personne();
        Employe employe = new Personne();
        ...
        Employe e = ouvrier.evolution();
        ....
    }
}

24/05/2007, 18h49
loverdose

Merci pour vos réponses !

En effet, l'approche avec utilisation de l'attribut me semblait plus naturel aussi car dans le cadre de mon problème, tel qu'il est aujourd'hui, un Employé ne diffère d'un Ouvrier que par sa nature et rien d'autres.

Ce qui m'a fait hésiter c'est que l'héritage me semble plus ouvert aux modifications, genre rajout de nouveaux comportements qui seraient différents pour Ouvrier et Employé.

Mais bon, je crois que je vais rester sur l'utilisation d'un attribut finalement, pour les modifications on verra par la suite :)

En tout cas :merci: !!