Bonjour, 

J'aurais une question concernant les interfaces (choses que je ne saisies pas très bien).

Mettons que nous ayons des classes MedecinsDAO et PatientsDAO qui font des appels à des bases de données et qui contiennent les fonctions suivante :

PatientsDAO

• inserer(Patients)
• modifier (Patients)
• supprimer(id)

Médecins 

• inserer(Medecin)
• modifier (Medecin)
• supprimer(id)

Souhaitant utiliser des interfaces pour implémenter chacune des classes je me demander qu'elle était la différence entre :

• Faire une interface par classe (genre IntMedecins et IntPatients)
• Faire une interface global pour les deux 

Essayons déjà de clarifier dans ta tête la notion d'interface.

Une interface c'est une version "allégée" d'un objet, le principe étant qu'elle ne contient PAS DE CODE, donc pas d'implémentation d'un traitement donné. (attention, désormais en JAVA on peut avoir du code dans les interfaces, ce qui rend plus difficile la compréhension).

L'interface c'est donc une vision PUREMENT abstraite d'une entité, d'un éléments de l'univers que tu es en train de modéliser.

Prenons le cas du DAO : on utilise une INTERFACE pour décrir le CONTRAT DE SERVICE qu'un objet IMPLEMENTANT CETTE INTERFACE doit pouvoir réaliser.

Sortons du domaine de l'informatique pour mieux comprendre : tu es une usine qui fabrique des objets A, et pour fabriquer A tu as besoin d'un composant B très spécialisé qui fait une petite fonction que, toi, tu ne sais pas faire. Tu vas trouver un fournisseur qui vend et fabrique B. Tu vas t'assurer de la manière dont B s'interface avec ton système A, et si tout est OK, alors tu peux utiliser B sans savoir comment il est fait à l'intérieur.

C'est le principe de la fabrication par composant.

Toi, le client, tu spécifies le CONTRAT (l'interface) dont tu as besoin, le niveau de service exigé....le fabriquant de B lui, respecte le contrat (il l'IMPLEMENTE) et te fourni un B qui est COMPATIBLE avec ton contrat, mais dont toi tu ne sais rien.

Dans ton exemple, ton DAO doit pouvoir LIRE/ECRIRE/MODIFIER/SUPPRIMER un médecin, un patient, que sais-je encore...

Ca c'est le CONTRAT DE SERVICE, donc l'interface.

L'implémentation de ce contrat peut être réalisée de différentes manières :

=> Un DAO basé sur XML qui lit et écrit des fichiers XML

=> Un DAO basé sur une base de données qui lit et écrit via JDBC natif, Spring JDBC Template, JPA+HIBERNATE...que sais-je...

=> Un DAO basé sur des fichiers properties

etc etc

Dans tous les cas, ces implémentations de DAO sont compatibles avec ton code : elles te garantissent que le contrat LIRE / ECRIRE / MODIFIER / SUPPRIMER est respecté.

L'interface est donc un moyen de découper un projet en zones de responsabilités, de MODULARISER le développement en coupant en deux un objet : l'interface d'un coté (le contrat de service) et l'implémentation de l'autre (la réalisation du traitement à proprement parler).

Dans un très gros projet, ce type de travail est fondamental car cela permet de créer des sous-projets, des équipes qui se coordonnent autour d'un même sujet, tout en isolant des parties, en permettant à chacun d'avancer sans marcher sur les pieds des autres.

En allant plus loin, on peut choisir d'ignorer la manière dont le DAO sera réalisé, mais on peut aussi choisir d'ignorer la manière dont les ENTITES sont réalisée, dont les SERVICES seront réalisés, etc, etc...

Bref, on peut spécifier un système complet sous forme d'interfaces, sans jamais écrire une seule classe d'implémentation, puis d'assembler des modules fournis par des gens qui ont créé des implémentations de telle ou telle partie du système et disposer d'un tout qui fonctionne.

Dès lors, tu dois comprendre que l'interface est un outil qui sert à décrire ton univers de façon la plus NATURELLE possible, et donc tu ne dois pas chercher à optimiser, à bricoler ou mélanger les notions : chaque notion doit être vue comme un élément propre.

Un médecin c'est un médecin, dont tu pourrais avoir une interface Medecin et une classe d'implémentation MedecinXML ou MedecinJPA par exemple.

Un patient ce n'est pas un médecin, donc un patient c'est une interface Patient, et une classe d'implémentation PatientJDBC ou PatientHIBERNATE ou que sais-je encore.

Après, parce qu'un patient et un médecin sont deux personnes physiques, deux individus, si à un moment tu as besoin de manipuler des listes d'individus, sans savoir si ce sont des médecins ou des patients (par exemple un annuaire d'individus), alors tu peux avoir une interface Individu qui comporte, par exemple, l'état civil, et faire hériter Patient et Médecin d'Individu...mais ce choix n'est à faire que si tu as des traitements collectifs à réaliser. Si la gestion des médecins et la gestion des patients n'amène jamais à considérer une liste mélanger des deux populations, alors créer un lien n'a pas de sens.

Je te remercie pour ta réponse elle est claire et je comprends beaucoup mieux la notion d'interface. 

Bonne journée