Discussion :

[pcdj]

Bonjour, dans plusieurs tutos traitant de la programmation orientée objet, on parle d'interface.

malgré des recherches sur divers sites, je ne parviens à bien comprendre leur utilité.

Quelqu'un pourrait il m'éclairer à ce sujet??

D'avance merci

[Jérôme Lambert]

Une interface, c'est un peu comme une classe abstraite sans les désavantages.

En fait une interface ne contient que des déclarations de méthodes. Une classe qui implémente une interface devra donc obligatoirement implémenter toutes les méthodes de l'interface en question.

[Thomas Lebrun]

Tu peux te représenter une interface comme un contrat.

Toute classe implémentant l'interface devra implémenter les méthodes qui la compose pour que le contrat soit respecté


A+


PS: Je déplace dans un autre forum

[N.Anis]

Oui Thoams,

les inetrfaces sont des contrats entre les classes qui implémente cette interface, une abstraction (c'est comme ça qu'on implémente l'abstraction avec les classes abstraite et les interfaces)

voici un exemple :

on a l'interface Isaisissable contient les méthodes setValeur() , getValeur()
et on a les classe TextField , numericField .. ils sont des calsses component il hérite respectivement de TextField , TextField (les composant standard de WinForms) ont les surcharges pour ajouter notre propre signature. et ces calsses implémente Isaisissable donc on doit implémenté obligatoirement setValeur et GetValeur dans chaque classe.

le but :
si on a des compoosants saisisable et d'autre non alors comment savoir les quelles sont saisisable

if (classe is Isaisable)
{
// Donc on peux faire le cast pare la suite on trouve la valeur du composant

((Isaisable)classe).GetValeur

}

[Exsilius]

J'ai également besoin d'eclaircissements au sujet de l'utilisation de 'interface'.

Lorsque ma classe parente implémente une interface, mes classes enfants ne sont apparement pas obligés d'instancier les méthodes de cette interface. Je suis obligé de les faire également implémenter l'interface en question.

Ai-je correctement compris ce point ?

Venant du C++ Win32, je trouve ça étrange que la classe enfant n'ait pas l'obligation d'instancier les méthodes de la classe parentes (comme c'est le cas en C++ pour les classes abstraites avec les fonctions virtuelles pures).

Deuxième précision : ai-je la possibilité de ne pas implémenter de méthode par défaut dans la classe abstraite parente (idem C++ avec fonctions virtuelles pures)

[N.Anis]

une classe qui implémente une interface doit obligatoirement implémenter tous ces méthodes.

pour la deuxiéme précission oui tu peux ne pas implémenter les méthodes dans la classe abstraite mais tu met juste la signature, et t'implémente la méthode dans la classe enfants.


autre chose ?

[Exsilius]

Merci N.Anis

une classe qui implémente une interface doit obligatoirement implémenter tous ces méthodes.

Je n'ai pas compris ce point. Je vais exprimer ma problèmatique plus clairement.

Ex :
J'ai une classe abstraite 'Organisme' qui hérite de l'interface IClonable
J'ai une classe enfant 'Humain' qui hérite de 'Organisme'.
Je pensais être contraint par le compilateur d'implémenter les fonctions de IClonable dans 'Humain'... et ça n'est pas le cas.

En fait, j'aimerais simplement retrouvé la logique des fonctions virtuelles pures du C++

[N.Anis]

Salut,

ta classe "Organisme" implémente IClonbale. donc donc vous avez implémenté les méthodes qui se trouvent dans l'interface dans la classe abstraite.

ta classe hérite de "Organisme" et Organisme implémente IClonable donc tu n'implémente pas les méthodes de IClonable dans ta classe mais dans "Organisme".

j'espére que vous avez compris

[Exsilius]

Cela signifie que si je veux obliger mes classes héritant de Organisme à implémenter certains fonctions, je ne peux pas utiliser les interfaces...

Merci

[Promeneur]

Cela signifie que si je veux obliger mes classes héritant de Organisme à implémenter certains fonctions, je ne peux pas utiliser les interfaces...

Merci

Si Organisme les implémente en tant que méthodes abstraites, les classes qui héritent devront les implémenter concrètement.

Une autre solution serait que les classes dérivées d'Organisme implémentent directement l'interface, alors qu'Organisme ne le fait pas (une interface n'est pas forcément implémentée dans une classe ancêtre).

Par ailleurs, comme avantage des interfaces, tu as le fait qu'une variable peut être de type d'une interface donnée, autrement dit elle accepte tous les objets qui implémentent cette interface. Cette façon d'implémenter le polymorphisme permet une sorte d'héritage multiple. Cela permet aussi de passer comme paramètre les objets qui implémentent ces interfaces.

[Exsilius]

Merci Promeneur.

C'est la première méthode m'intéresse puisque j'aimerais que classes enfants n'ait aucune interface à hérité.

Pourrais tu me donner un peu plus de détail au niveau de la syntaxe.

A priori, ni mon interface ni ses méthodes ne doivent être abstraite dans leur déclaration.

Je suppose donc que c'est effectivement lors de leur implémentation dans la classe mére que je les déclare 'abstract'. Mais là, nous avons semblet-il quelques problèmes de syntaxe...

[Mose]

Une interface, c'est un peu comme une classe abstraite sans les désavantages.

C'est quoi les "désavantages" d'une classe abstraite ?
Moi je vois plutôt plein d'avantages à la classe abstraite par rapport à l'interface : tu peux y mettre du code et tu peux y mettre des champs

[Bluedeep]

Une interface, c'est un peu comme une classe abstraite sans les désavantages.

Cette définition me semble quelque peu biaisée ....

Je ne vois ni avantage ni désavantages à une classe abstraite vs une interface. Ce sont deux choses pour deux usage différents.

[Mose]

Cette définition me semble quelque peu biaisée ....

Je ne vois ni avantage ni désavantages à une classe abstraite vs une interface. Ce sont deux choses pour deux usage différents.

En terme de polymorphisme, y'a quand même un gros gros point commun... et donc un usage similaire
Mais bon... chui d'accord que dans 90% des cas ces deux solutions ne sont pas intervertible.

[Jérôme Lambert]

Cette définition me semble quelque peu biaisée ....

Je ne vois ni avantage ni désavantages à une classe abstraite vs une interface. Ce sont deux choses pour deux usage différents.

Je ne voulais pas être négatif en disant ça.

c'est juste que lorsqu'une classe implémente une interface, elle implémente toutes les méthodes de cette interface et puis c'est tout.

Les classes abstraites représentent tout un processsus en terme de compréhension et de manipulation bien plus élaboré: On peut aller très loin mais avec difficulté par moment lorsqu'on est novice.