Discussion :

[loverdose]

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?

[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

[Nikk0]

Salut,

+1 pour la solution d'héritage ..
créer une personne et ensuite tu fais hériter ouvrier et employé

[guis14]

+1 aussi pour l'heritage ...

[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 ....

[Nesmontou]

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

Code :

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

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

[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é ) et chaque employés à un type.