Questions sur des termes POO

Salut les agrumes ,
J’ai des difficultés à bien saisir la signification de certains termes de POO comme la notion d’interface et d’abstraction.J’ai l’impression que leur sens suivant le contexte dans lequel on les utilisent.

Par exemple dans le principe "Programmez pour une interface pas pour une implémentation" Est ce qu’ici la notion d’interface fait référence à un groupe de méthodes/fonctions ? Dans ce cas je n’arrive pas à saisir le sens de la phrase

Deuxième exemple , dans le principe d’inversion des dépendance , il est écrit vos modules de haut et bas niveau ne doivent pas dépendre de classes concrètes (ou de détails d’implémentations) mais d’abstraction.Ce que je ne comprend pas ici c’est qu’une classe concrète est déjà une abstraction.

Voilà j’espère que vous pourrez m’aider ,bonne journée et merci d’avance pour vos réponses

J’ai des difficultés à bien saisir la signification de certains termes de POO La POO n’est pas un domaine "dogmatique". La POO varie plus ou moins en fonction des langages de programmation qui l’illustre. Il faut être assez souple sur les définitions et elles sont assez souvent fonction du contexte.

comme la notion d’interface "interface" pour un C++-iste ou un JAVAiste ne représente pas la même chose, donc…

et d’abstraction. "Abstraction" c’est assez vague et générique comme terme.

J’ai l’impression que leur sens suivant le contexte Oui.

Est ce qu’ici la notion d’interface fait référence à un groupe de méthodes/fonctions ? Là, c’est un tic de JAVAiste qui comprend "interface" par la signification du mot clé du langage. Ici, ce n’est pas vraiment l’aspect regroupement de méthode mais plus le fait qu’on doit se baser sur les signatures et d’éventuelle regroupement de méthodes/fonctions que sur leur implémentation. C’est un peu comme dire qu’il faut que les API encapsulent des "boites noires" où les détails d’implémentation n’ont pas à interférer avec la conception de l’API.

Ce que je ne comprend pas ici c’est qu’une classe concrète est déjà une abstraction. Une classe concrète a aussi une implémentation mais il ne faut pas que le code qui utilise la classe se serve des détails d’implémentation. En utilisant des classes "interface à la JAVA", le code utilisateur d’une méthode n’est dépendant que de la définition de l’interface et non de son implémentation dans une classe => il y a un niveau d’abstraction entre le code utilisateur et la classe implémentation via l’interface.

Si vous commencez à regarder les Design Pattern de création d’objet, vous verrez des applications de ce type d’abstraction.

Par exemple dans le principe "Programmez pour une interface pas pour une implémentation" Est ce qu’ici la notion d’interface fait référence à un groupe de méthodes/fonctions ? Dans ce cas je n’arrive pas à saisir le sens de la phrase

L’idée c’est qu’une interface va spécifier le contrat que les fonctions vont avoir et que ca te suffit pour réaliser ce que tu souhaites. Le système réel qui va implémenter cette interface va ajouter plein de détails (nécessaires à l’implémentation) mais dont toi tu te fiches.

Par exemple dans le domaine de la robotique, une interface Déplacer a 2 fonctions:

• avancer(double x) va dire au robot d’avancer de x mètres
• rotation(double x) va lui dire de tourner sur lui même de x radians.

L’idée ces que informations là sont suffisantes pour réaliser ce dont tu as besoin (aller d’un point $A$ à un point $B$). Ton robot concret (qui implémentera l’interface que j’ai décrite) aura peut être 2 roues, à 4 roues ou encore 2 jambes. On s’en fiche ! Les commandes ne seront pas les mêmes selon le type de robot mais de ton point de vu, c’est un détail dont tu n’as pas besoin. mais la La fonction réalisée est la même!

Deuxième exemple , dans le principe d’inversion des dépendance , il est écrit vos modules de haut et bas niveau ne doivent pas dépendre de classes concrètes (ou de détails d’implémentations) mais d’abstraction.Ce que je ne comprend pas ici c’est qu’une classe concrète est déjà une abstraction.

Le DIP est dans la même veine que l’idée précédente. Au lieu de dépendre qu’une classe A dépende directement d’une classe $B$, on va préférer que $A$ dépende d’une interface I et que $B$ implémente cette interface I. Ainsi, tu as un couplage plus faible entre A et B et ca peut être plus facile de raisonner avec I qu’avec B. Tu peux envisager de remplacer facilement B par une classe B2 tant que celle ci implémente l’interface I, tu as un code plus générique.

Si je reprends mon exemple de robot, un module d’IA va dépendre d’une interface Déplacer au lieu de dépendre directement de Robot2Roues ou de Robot4Roues.

Merci de m’avoir répondu @Davidbrcz ,mais j’avais compris les idées derrière ces notions ,ce que je demandais c’était à quoi fait référence exactement la notion d’interface (qui est différente de la notion d’interface en java et je crois que tu fais la confusion entre les deux) et qu’est ce que signifie "Programmez pour une interface" (toi tu expliques programmer une interface) ça c’était pour le premier principe

Dans le deuxième principe je demandais ce que signifiait "abstraction" dans ce principe car une classe concrète est aussi une abstraction.

J’ai jamais écrit la moindre ligne de Java, mais sa définition d’interface me parait tout à fait valable. L’interface d’un objet, c’est l’ensemble des méthodes et attributs qu’il présente.

Alors là je crois que tu commet une énorme erreur l’interface d’un objet c’est uniquement ses méthodes publique et éventuellement les fonctions manipulant le dit objet( prenant en paramètre l’objet en question ) et absolument pas ses attributs !

Et lorsque je me suis renseigné j’ai remarqué q’une interface pouvait être aussi bien une classe abstraite , une interface (comme en java) voir même simplement même une simple classe mère.

Si tu as compris ce que sont des interfaces, des classes et des abstractions, je me demande bien ce que tu attends de nous.

Justement si tu avais pris le temps de lire mon message jusqu’au bout tu aurais compris que c’était sur ces notions que je posais mes questions.

Alors là je crois que tu commet une énorme erreur l’interface d’une objet c’est uniquement ses méthodes publique et éventuellement les fonction manipulant le dit objet( prenant en paramètre l’objet en question ) et absolument pas ses attributs !

Ben si tu connais mieux le sujet que nous, je ne comprends pas l’intérêt d’ouvrir un sujet.

Et lorsque je me suis renseigné j’ai remarqué q’une interface pouvait être aussi bien une classe abstraite , une interface (comme en java) voir même simplement même une simple classe mère.

Une classe abstraite sert à définir une interface, Java je connais pas, et une classe mère sert à implémenter une interface (et éventuellement la définir au passage).

Ben si tu connais mieux le sujet que nous, je ne comprends pas l’intérêt d’ouvrir un sujet.

J’essaye de recouper et de vérifier les informations que j’ai trouvé autre part c’est ça l’intérêt et de de vérifier si j’ai bien compris .

En fait, je faisais surtout référence au ton de tes messages avec une petite pointe d’ironie. Plutôt que de dire "je croyais que les attributs ne font pas partie d’une interface", tu pars direct sur "je crois que tu fais une énorme erreur [bla bla]". Quand on demande des explications sur un sujet, remettre en cause ce que tu pensais savoir à partir des réponses que tu reçois et soulever ces points là, c’est bien. Partir du principe que ce sont les gens qui te répondent qui n’ont pas compris, c’est inverser les rôles et ça donne pas franchement envie d’aller plus loin. C’est peut être une simple question de formulation, auquel cas tant mieux et je te conseille juste de faire gaffe à la façon dont tu réponds aux gens qui viennent là pour t’aider dans la bonne humeur.

@adri1 : Je ne vois pas en quoi dire "je crois que tu fais une énorme erreur" est un problème je me suis basé juste sur mes connaissances ,et je suis resté poli, après je pense que tu te vexes facilement ,donc si je t’ai vexé je m’excuse .

NB : Mais bon dire que les attributs font partis de l’interface quand on fait de la poo c’est limite donc si tu n’es pas sûr de tes informations ne les écrits pas.Voilà comme ça moi aussi je te donne un conseil

Je ne suis aucunement vexé, je te dis juste de faire attention à la façon dont tu exprimes les choses. Même si ce n’est pas volontaire, écrire des choses du genre "je crois que tu fais la confusion entre les deux", "toi tu expliques programmer une interface", etc donne l’impression que tu prends tes interlocuteurs de haut et que tu leur expliques gentiment qu’ils ne comprennent pas de quoi ils parlent où répondent à côté de la plaque alors que c’est toi qui demande des explications sur le sujet. Encore une fois, ce n’est visiblement pas volontaire de ta part, donc il n’y a pas de problèmes de fond, c’est juste une question de formulation.

Maintenant, je disais juste ça comme ça, tu en fais bien ce que tu veux, pas la peine de s’éterniser.

EDIT : "Mais bon dire que les attributs font partis de l’interface quand on fait de la poo c’est limite donc si tu n’es pas sûr de tes informations ne les écrits pas." C’est typiquement ce dont je parle. Tu te fourres royalement le doigt dans l’œil sur ce point, mais tu es tellement sûr de toi que tu pars du principe que la personne qui te répond a tort. C’est assez comique quand on y pense. Peut être que dans le cadre d’un langage particulier (Java peut être?), il est impossible de définir une interface avec des attributs, mais cette restriction n’existe pas en général.

Est-ce que tu as encore des questions sur le sujet initial ou pas ?

. Tu te fourres royalement le doigt dans l’œil sur ce point.

"En programmation orientée objet, une interface est un ensemble de signatures de méthodes publiques d’un objet. Il s’agit donc d’un ensemble de méthodes accessibles depuis l’extérieur d’une classe, par lesquelles on peut modifier un objet, ou plus généralement communiquer avec lui" D’après wikipédia ,première page de la recherche Interface POO.

Maintenant partons du principe que j’ai tort ,prouve moi ou montre moi quelque chose ou il est marqué que les attributs font partis de l’interface d’une classe . Et là je pourrai te croire.Il faut apporter des preuves quand tu tentes d’expliquer des chose tu ne peux pas te contenter de dire crois moi sur parole.

Est-ce que tu as encore des questions sur le sujet initial ou pas ?

Oui j’attends que quelqu’un soit me prouve que j’ai tort sur ces notions là ou que mes informations sont fausses mais en ayant des preuves et en argumentant ou que j’ai raison .

Python : https://docs.python.org/3/library/abc.html#abc.abstractproperty

C# : https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties

Pourquoi vouloir marquer une différence nette entre méthodes et attributs ? Tu peux aussi voir une méthode comme un attribut que tu peux appeler¹.

Ça va servir à quoi de savoir qu’une classe concrète est une abstraction ou non ?

Si on part sur le principe que tu as raison, ça va donner quoi au niveau du code ?

Ou considérer un attribut comme étant une méthode invariante (ou pas invariante d’ailleurs, mais c’est plus surprenant).

J’ai l’impression que sur cette histoire d’attributs dans les interfaces, il y a une confusion entre :

1. La POO « théorique » (et qui n’existe pratiquement pas en réalité), dans laquelle ce qui importe sur un objet, c’est la façon dont on l’utilise indépendamment de son implémentation. Donc à priori on voit peu d’attributs dans une interface qui est la définition d’une implémentation (voire pas du tout pour certains puristes).
2. La POO « réelle » avec une tendance fâcheuse à coller des getters/setters publics pour tous les attributs de l’objet. Ce qui revient souvent à coller des tas d’attributs dans une interface.

Bof, même d’un point de vue théorique dire "pour implémenter cette interface, faut fournir tel attribut" c’est exactement le même délire que "pour implémenter cette interface, faut fournir tel méthode".

Typiquement, la méthode __len__ requise par l’interface Sized en Python, dans l’absolu ce serait un attribut et pas une méthode, ce serait exactement pareil. Un attribut, on peut toujours l’implémenter comme une méthode qui ne prend que l’objet en argument (ce que font les getter en fait).

Faire le distingo attribut/méthode, ça me parait pas capital.

@adri1 :Je ne programme pas en C# et dans tes exemples je ne vois pas où sont déclarés tes attributs .

@entwanne : Tu as sûrement raison , car je m’y connais pas trop en python , cependant et je pense que je me suis mal exprimé ,je demandais , la notion d’interface mais dans son sens global pas en Python ou en C# ou dans un langage particulier ,ainsi que la notion d’abstraction dans le contexte des deux principes que j’ai cité plus haut.

@SpaceFox : oui et moi je veux parler de poo théorique ,je crois que tu m’as compris .

Faire le distingo attribut/méthode, ça me parait pas capital.

@Adri1 :D’après moi ,après j’ai peut être tort mais une méthode est censé représenter une fonctionnalité ,donc le vrai débat serait de dire est ce que un getter ou un setter est vraiment une méthode parce que c’est équivalent la plupart du temps à mettre directement l’attribut en question en public et non en privé.