Questions sur des termes POO

parce que c’est équivalent la plupart du temps à mettre directement l’attribut en question en public et non en privé.

Personnellement il m’arrive souvent d’avoir des getter, moins des setteurs. En effet le fait que ce soit disponible en lecture seule vis à vis de l’extérieur est souvent utile et rarement proposé nativement par les langages.

Et un setter peut aussi vérifier ou travailler la valeur en entrée avant de l’appliquer sur l’attribut. Cela peut être utile pour garantir la validité de l’objet.

Avoir un attribut, c’est une fonctionalité.

Maintenant, on s’en fout pas mal parce qu’une interface définit un comportement. Que ce comportement implique seulement des méthodes ou aussi des attributs ou encore autre chose, ce sera dépendant du langage dans lequel l’interface en question est définie. Dans tous les cas, c’est un détail qui n’est pas capital pour comprendre les relation entre classe, interface, et implémentation.

Je suppose que la distinction méthode/attribut est importante dans les langages où on ne peut pas surcharger les attributs – et qui donc ne peuvent généralement pas avoir d’attributs dans les interfaces.

En effet, si on peut pas surcharger les attributs, les mettre dans une interface n’a aucun sens.

Bon déjà merci à tous pour vos réponses ,je vais essayer de synthétiser ce qui a été dit ,dites moi si j’ai bien compris :
Déjà pour la notion d’interface :
- Dans le cadre de la poo théorique il s’agit d’un ensemble de signature de méthodes permettant de manipuler un "type".
- Il existe aussi une version plus générale de la notion d’interface qui prend en compte tout ce qui est dans la portée publique c’est à dire méthodes + attributs + tout autres fonctions permettant de manipuler l’objet en question (fonction libre , opérateurs …)
Donc si on reformule de premier principe cela devrait donner :
Programmez des classes abstraites ou des interfaces(au sens de Java) ,pas des implémentations.

Pour la notion d’abstraction son interprétation dépend de son contexte , car il y a différents niveaux d’abstractions : la classe est une abstraction d’un concept , et l’interface (au sens POO du terme ) est une abstraction d’une classe.
Du coup si on reformule le deuxième principe cela devrait donner :
Les modules de haut et de bas niveaux ne devraient pas dépendre de détails d’implémentation(classes concrètes) mais de classes abstraites ou d’interfaces (au sens Java )

Voilà j’espère n’avoir rien oublié , si j’ai dit une bêtise n’hésitez ou oublié quelque chose n’hésitez pas à me de le dire.

PS : Et je tenais à m’excuser pour l’accrochage qui eu lieu en début de post .

J’ai l’impression que ce que tu appelles « POO théorique » c’est « POO selon Java », parce que je ne vois pas pourquoi il y aurait une différence de définitions entre « POO théorique » et « version plus générale ».

Je pensais que la poo "théorique" ne s’intéressait qu’au paradigme objet et pas au paradigme fonctionnel , et que donc en terme de poo "théorique" on aurait idéalement que des classes et pas de fonction libre par exemple et que donc est que dans ce cadre là dire qu’une fonction libre fait partie d’une interface aurait du sens ?

Mais ça encore une fois c’est plutôt propre au style Java.

Déjà, les classes ne sont pas nécessaires pour faire de la programmation objet. Mais pour les langages qui en disposent, des fonctions hors de toute classe peuvent s’inscrire dans une conception objet (une fonction statique main n’a pas d’intérêt particulier à être intégrée dans une classe, par exemple).

Et paradigmes fonctionnel et objet ne s’opposent pas nécessairement, jette un œil à l’OCaml par exemple.

Effectivement , donc je garde la version générale d’interface .

Plusieurs problèmes.

La "définition" historique de l’OO est assez éloignée de ce qui est pratiqué dans les langages mainstreams qui disent supporter l’OO. Kay regrette d’ailleurs d’avoir utilisé le mot "object" car les gens ne se sont pas concentrés sur la chose importante : la communication. De plus, presque on pourrait dire que Java & cie sont en fait orientés classes. Or c’est limite contraire aux fondements même de l’OO de Kay. Avec les interfaces java/UML, nous sommes en plein typage, et donc en pleine contradiction avec la flexibilité ultime du "extreme late-binding of all things".

Aussi, si les langages OO mainstream ont une base procédurale, un des langages les plus OO selon Kay était CLOS qui lui a une base LISP et donc totalement fonctionnelle. Les principes OO sont orthogonaux à procédural/fonctionnel.

Et d’un point de vue tout à fait pragmatique, en presque 10 ans de carrière et beaucoup plus de projet, je n’ai jamais vu de code qui respecte mieux que « vaguement » les principes de la « POO telle qu’elle devrait être selon le cours » (le tout généralement appliqué à Java, mais pas que).

Autant te dire que pour ce qui est de respecter l’OO « historique », on est carrément dans le fantasme.

(mon avis personnel est qu’on devrait avoir des machines à états qui communiquent entre elles, mais je suppose qu’on s’éloigne du sujet. Mais j’aime bien les machines à états)

Merci pour vos réponses détaillées , @lmghs et @SpaceFox ,je prends note. (Même pour la machine à états )

Donc si je reprends avec les modifications que vous m’avez indiquées : Pour le premier principe cela pourrait être équivalent à dire que l’on doit assurer les fonctionnaltés exposées par l’interface au sens large , sans s’occuper du comment.
Pour le deuxième principe on pourrait dire que les modules de haut et bas niveaux devrait dépendre d’une abstraction c’est à dire d’une d’une classe mère (abstraite ou non) (Car elle pourrait être considérée comme une abstraction de sa classe fille ).
Désolé si je suis un peu lourd mais je veux comprendre ,donc j’insiste un peu

J’ai édité mon message précédent ,est ce correct maintenant  ?

J’ai tendance à résumer la programmation orienté objet, de manière la plus générale, comme :

C’est probablement un peu naif comme vision, peut-être trop générique (voir pouvant inclure des choses étrangères à la POO). Mais ca m’a toujours suffit pour appréhender les différents principes et réflexions sur la POO, dans un cadre suffisamment large et avec un vocabulaire éloigné de la plupart des langages.

Si je reprends les principes SOLID, par exemple :

• Single Responsibility Principle : Un agent ou un message n’a qu’un seul rôle, tu dois pouvoir le résumer en une phrase simple
• Open Closed Principle : De nouveaux messages peuvent être ajouté à un agent, mais le rôle d’un message ne peut être modifié
• Liskov Substitution Principle : Un agent peut être substitué par un autre si il peut recevoir les mêmes messages
• Interface Segregation Principle : L’ensemble des messages auxquels un agent peut répondre doit être le plus petit possible
• Dependency Inversion Principle : La réponse à un message doit être formulée en fonction d’autres messages, pas d’agents particuliers

Par dessus, on pourrait rajouter quelques éléments :

• Si deux agents acceptent un même groupe de messages, ce groupe forme un contrat
• De plus si ce groupe est exclusif et que les agents y répondent de la même façon, ils sont de la même espèce
• Si le groupe de messages d’une espèce est inclus dans le groupe d’une autre, alors la seconde est une sous-espèce de la première

Si tu prends un langage particulier, tu vas retrouver les agents/messages/espèces/contrats/sous-espèce avec une autre terminologie. Pas forcément les quatre, et surtout, un langage ne va que fournir les outils, mal utilisé ils ne vont pas du tout refléter une vision orienté objet.

Par exemple, en C++, un agent est un objet (au sens de la norme, un espace mémoire avec un type), une classe est une espèce, une classe fille est une sous-espèce. Les messages sont tous ce qui est accessible : fonctions (libres ou liées publiques) et les attributs publiques. Et j’ai pas assez suivi les dernières avancées du C++ pour dire si il y a des contrats ou juste sous une forme affaiblies.

PS: Ce n’est qu’un point de vue, sujet à critique et discussion.

@Freedom je n’ai pas bien compris ta vision du principe Dependency Inversion Principle , est ce que tu pourrais donner un exemple ?

@Octodex : il y a une analogie que j’aime bien par rapport au DIP et au OCP :

Imagine toi que tu es un fabriquant de télévision qui ne respecte ni l’un ni l’autre

Tu as donc une télé, qui sait afficher une image, chouet.

Mais maintenant, tu veux pouvoir jouer à ta console de jeux vidéo. Du coup, comme elle ne respecte pas le principe "overt/fermé" il va falloir que tu aille trifouiller ta télévision pour que la console puisse être utilisée.

De même lorsque tu voudrais utiliser un lecteur DVD ou blue ray (paraît qu’on est en 2018).

Et puis un jour tu vas vouloir afficher une image HD, voire 4K, donc il va falloir trifouiller ta télévision etc.

Le OCP te dit que tu vas cacher comment est faite ta télé, par contre tu vas lui fournir un ensemble d’entrée (une interface) avec laquelle elle pourra discuter. Une entrée VGA, HDMI, DP, antenne par exemple. De plus tu vas lui ajouter une prise interne à laquelle sera branché un décodeur TNT, qui lui connaîtra un ensemble type de "message" : le protocole DVB dans différente version par exemple.

Ce tunner ne doit pas réagir différement en fonction du message lui-même, mais du protocole du message (tiens, encore une interface). En gros le tuner n’a pas été créé en fonction du nombre de chaîne au moment où il a été fabriqué, ni même en fonction de la dynamique des programmes (un film d’action est plus dynamique qu’un documentaire animalier en terme de colorimétrie par exemple) on lui a dit "DVB" c’est X choses à respecter, si tu les respectes c’est bon.

Et maintenant peu importe le nombre de chaînes, la dynamique des programme ou la résolution, du moment que ton tunner est compatible avec la version du DVB actuelle, tout est ok.

Le DVB ne dépend pas des tunner, d’où le concept "d’inversion de la dépendance".

Merci pour vos réponses ,je vais mettre le sujet en résolu .

Merci pour les liens @lmghs je vais regarder tout ça .