Discussion :

[Amnael]

Bonjour, bonsoir à tous,

étant en pleine révision, je viens vous poser une question: Comment justifier l'implémentation d'une classe abstraite ou d'un interface ou d'une classe normale ?

J'imagine qu'il y a plusieurs critères permettant de faire ces choix et ainsi de pouvoir justifier, mais j'aimerais en avoir le cœur net.

Je sais que l'on ne peut hériter que d'une seule classe et que l'on peut implémenter plusieurs interfaces, donc on peut imaginer que parfois l'utilisation d'interfaces permettent de contourner le problème d'héritage multiple non proposé par Java ?


Cela dit, c'est la seule différence que je vois entre classe abstraite et interface...les deux ne peuvent pas être instancié (sauf erreur de ma part).


Afin de travailler sur ces questions là, je vous propose ce sujet

Ce sujet a pour but de calculer le salaire de différents employés d'une entreprise en fonction de leur poste, de leurs horaires etc etc...Vous implanterez les propriétés suivantes introduites progressivement à chaque question par des interfaces, des classes abstraites ou des classes concrètes dont vous justifierez le choix. A chaque fois, sauf indication contraire, le code java complet est demandé.

Pour moi, la difficulté principale de cet énoncé est de devoir justifier mes choix d'implémentation.

1- Un salarié a un salaire (opération retournant un double). Définir en Java la notion de Salarié.

2-Une prime est définie par un montant (opération retournant un double). Définir en Java la notion de Prime.

3- Une prime de risque est une prime dont le montant est défini par une constante fixé (PRIME), d'une valeur de 100.0 euros. Définir en java la notion de PrimeDeRisque

4- Une salarié primé est un salarié ayant une prime (fournie à la construction et pouvant être lue). Son salaire est calculé comme la somme d'un salaire de base et du montant de la prime. Le mode de calcul du salaire de base n'est pas connu ici et dépend du type de salarié primé. Définir en java la notion de SalariéPrimé

5- Une prime de nuit est une prime accordée à un salarié primée. Elle est définit par un coefficient multiplicateur, encore appelée COEFPRIME et fixé à 1.5. Ce coefficient s'applique au salaire de base de l'employé pour donner le montant de la prime de nuit. Définir en java la notion de PrimeDeNuit.

6- Les deux primes, primes de nuit et prime de risque peuvent être cumulées (leurs montant s'ajoutent). On introduit une prime de risque de nuit qui est à la fois une prime de risque et une prime de nuit.
a- Cependant, il n'est pas possible de la définir par utilisation de l'héritage. Pourquoi ?
b- On considère une prime de risque de nuit est une prime de nuit contenant une prime de risque. Définir en java la notion de PrimeDeRisqueDeNuit.
c- On considère une prime de risque de nuit est une prime de risque contenant une prime de nuit. Définir en java la notion de PrimeDeRisqueDeNuit.

Pour la suite, on suppose qu'un employé est un salarié ayant un nom. Une classe Employé, dont le code n'est pas demandé implante ce concept et permet de définir le nom par paramétrage du constructeur.


7- Un technicien est un employé dont le salaire est proportionnel au nombre de pièce qu'il fabrique. Le coefficient est fixé (10 euros par pièces). et le nombre de pièces fourni par le constructeur. Définir en Java la notion de Technicien.

8- Un vendeur est un employé dont le salaire de base est calculé en fonction de son chiffre d'affaire (fixe de 500 euros + 5% de son chiffre d'affaire). Un représentant est un employé dont le salaire de base est calculé de la même manière (fixe de 1000 euros +5% de son chiffre d'affaire).
Sachant que le chiffre d'affaire de ces employés est fourni par le constructeur, définir deux classes en faisant en sorte de factoriser les informations communes. Des déclarations non explicitement demandées devront être ajoutées.

9- L'ensemble du personnel est représenté par un tableau d'employé, le nombre maximal d'employé étant de 200. Définir la classe Personnel avec un constructeur, une opération permettant l'ajout d'un employé (un message d'erreur sera affiché en cas de débordement), une opération retournant le salaire moyen des employés et la méthode toString() retournant une chaine contenant le nom et le salaire de chaque employé.


10- Un technicien à risque est à la fois un technicien et un salarié primé.

a- Quel problème pose la transcription de cette propriété
b- Introduire sous forme graphique les structures permettant d'exprimer cette propriété. Aucun code n'est demandé.
c- Proposer une implémentation de TechnicienARisque exploitant une classe interne. On utilisera la notation C.this.m() dans une méthode de la classe interne pour appeler la méthode m() sur l'objet englobant.

A partir de ce sujet, avant même de s'attaquer au vrai codage, je voudrais arriver à comprendre comment déterminer les choix d'implémentation: Interface, classe abstraite ou classe normale.



Q1 et Q2 - En ce qui concerne Salarié et Prime, j'aurais réalisé des classes abstraites car on n'a pas besoin d'instancier un salarié seul ou une prime seule. Mais du coup, un interface serait aussi envisageable non ? Comment choisir ? Autre question, les notions de salaires et de montant de ces deux classes font elles références à une variable ou bien une méthode devant retourner un double ?

Je vais pour l'instant stopper la ma réflexion, étant donné que la réponse de ceux deux premières questions vont pour ainsi dire conditionné tout le reste...par exemple s'il s'agit bien d'une méthode dans une classe abstraite, ces méthodes devront être définis dans l'héritage etc etc...
J'ai l'impression que tout va découler du choix réalisé dans ces deux premières questions.


Merci !

[tchize_]

Une interface, faut voir ça comme un comportement, que des tas d'objets n'ayant rien à voir entre eux peuvent potentiellement avoir.
Une classe abstraite c'est un objet, ça a une véritable existence (pas juste un comportement) mais il n'est pas complet. Par exemple un Animal peut être vu comme abstrait car son comportement "se déplacer" dépend du type d'animal (oiseau, etc.).

Reprenons ta prime. Est-ce un comportement? Est-il logique qu'un travailleur soit une prime? Qu'une chaise soit une prime? ... Non, a priori un Prime, c'est une valeur encapsulée dans un objet, pas besoin d'en faire une interface. Je ne vois pas pourquoi on ne pourrait pas d'ailleurs instancier un travailleur sans prime Ou une prime sans travailleur. Après tout on pourrait associer la prime à un poste qui est à pourvoir.

[Amnael]

Donc, mes primes et salariés sont bien des classes abstraites ?

Ce qui nous amène ici

6- Les deux primes, primes de nuit et prime de risque peuvent être cumulées (leurs montant s'ajoutent). On introduit une prime de risque de nuit qui est à la fois une prime de risque et une prime de nuit.
a- Cependant, il n'est pas possible de la définir par utilisation de l'héritage. Pourquoi ?

Impossible car cela impliquerait un héritage multiple.

Et au niveau de la question 10 c'est le même problème si je ne m'abuse ?

[professeur shadoko]

en général une classe abstraite est la définition d'une mutualisation de code.
donc tu peux avoir une prime abstraite et deux sous-classes qui ne peuvent pas hériter l'une de l'autre.
exemple classique:
client (ou autre) : classe abstraite
personne physique: sous-classe
personne morale: sous-classe
mais personne physique et personne morale ne peuvent hériter l'une de l'autre (enfin dans l'univers de la programmation)

bon ici le problème de la prime de risque de nuit est différent ..... une interface?

un pattern classique est d'hériter d'une classe et de référencer un autre qui implante une interface commune:
exemple: dans une banque le ClientSalarié hérite de Client et implante l'interface EstSalarié
le Salarié implante l'interface EstSalarié
le ClientSalarié opére par délégation sur un Salarié. (Il hérite des méthodes de Client et les méthodes définies par le contrat EstSalarié sont réalisées par délégation
sur une référence vers un Salarié)

[Amnael]

Pourriez vous me dire si ce que j'ai fais semble correct vis à vis de l'énoncé pour ces 4 premières questions:


Q1-

Code :

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

1
2
3
4
public interface Salarie {
	public abstract double salaire();
 
}

Q2-

Code :

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

1
2
3
public interface Prime {
	public double montant();
}

Q3-

Code :

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

1
2
3
4
5
6
7
8
public class PrimeDeRisque implements Prime{
	private final double PRIME=100.0;
 
	public double montant(){
		return PRIME;
	}
 
}

Q4-

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public abstract class SalariePrime implements Salarie{
	private Prime maPrime;
 
	public SalariePrime(Prime p){
		maPrime=p;
	}
 
	public double getSalaire(){
		return maPrime.montant()+this.salaire();
	}
 
}

S'il y a des erreurs je voudrais bien comprendre d'où elles viennent.

Merci pour votre patience