Discussion :

[dibax10]

Bonjour,

Je souhaites savoir pourquoi on a déclarer une interface étudiant et on lui donne un nouvelle objet EtudiantDAO

Code :

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

1
2
3
4
 
		Etudiant e1= new Etudiant("0499499RR","alami","karim","2/2/1990","casa");
		IEtudiant metier = new EtudiantDAO();
		metier.ajouterEtudiant(e1);

Merci

[joel.drigo]

Salut,

Dans l'expression IEtudiant metier = new EtudiantDAO();, on déclare une variable metier de type IEtudiant et on lui affecte une instance d'objet de classe EtudianDAO.

Ceci nécessite pour commencer que la classe EtudiantDAO implémente directement ou indirectement l'interface IEtudiant (c'est probablement une interface). Il est toujours préférable de typer par l'interface la plus générique possible (ou la classe le cas échéant), tant qu'on a à disposition sur la variable les méthodes qui nous sont nécessaires à la manipulation (et c'est le type qui permet au compilateur de connaître ces méthodes). Ceci permet éventuellement de faire des méthodes qui ne traitent que de l'interface générique et pas de la classe concrète spécifique, ou d'une interface/classe plus spécifique, , donc plus générique qu'une méthode qui traiterait de la classe spécifique, et donc, de pouvoir les invoquer dans un plus grand nombre de cas (donc de limiter la duplication de code). Cela pourra t'être utile en particulier si tu fais des tests unitaires avec un mock (une implémentation concrète de IEtudiant qui n'utilise pas la base de données comme source et qui sert de base pour pouvoir faire des tests unitaires avec des contenus de référence pour tester tes développements, donc pas EtudiantDAO). D'ailleurs, de la même façon, tu pourrais avoir la même construction pour la variable e1 (la typer avec une interface plus générique que l'implémentation concrète Etudiant).

[OButterlin]

Il est certain qu'écrit comme ça, ça n'a pas beaucoup d'intérêt d'utiliser l'interface plutôt que le type EtudiantDAO...

Ceci dit, si tu passais par le pattern Factory, ça prendrait tout son sens
L'intérêt serait alors de substituer une classe à une autre en fonction de contraintes et de la "traiter" sous sa forme contractuelle (l'interface) sans avoir à te soucier du type réel.

[dibax10]

Donc si j'ai bien compris, cela permet de rendre le code plus générique et donc éviter de répéter le même code dans la classe Etudiant, ce qui permet d’initialiser un nouvelle objet Etudiant si la classe implémente les méthodes de l'interface. C'est bien ca ?

[joel.drigo]

Non, non pas tout à fait.

Code plus générique oui. Mais ça n'a aucune action sur l'implémentation de la classe Etudiant. C'est juste la variable metier qui est impactée, son type en particulier. Tu peux donc modifier l'instanciation (la classe invoquée par le new) sans impact sur le type de la variable, tant que la classe est compatible bien sûr.

[dibax10]

C'est bon j'ai compris, merci