Discussion :

[DMontaut]

Malheureusement, Encore aujourd'hui

En programmation, si on ne connaît pas bien la composition de la lessive, si on ne sait pas exactement comment il faut s'adresser à notre objet, savoir si en fonction de la langue qu'on parle (ah si il complète nos mots automatiquement... bon parfois on fait pas attention et on s'aperçoit pas qu'il a compris "Blanc" au lieu de "Couleurs fragiles"), de celle de notre blanchisseur, qu'en fonction de la version de la machine à laver qu'il va utiliser et du modèle (Ios,Android,Win...) de l'interface (le comptoir), savoir si on lui a bien donné tous les paramètres et comment les formatter : à quelle date je veux récupérer mes vêtements propres (il faut de l'espoir) : "01/12/2015" ou #12/01/15# ou 886775, etc..., etc...

On n'est pas sûr d'obtenir le résultat attendu : tiens voilà, mon linge, rends-le moi propre le plus vite possible.
Sans oublier : S'il vous plait et Merci.

Et quand au retour, on lui fera remarquer qu'il reste une tâche...

[psykokarl]

Je pense que tu sur-estimes le problème lié à l'encapsulation qui limiterait la modularité : on y est parfois confronté mais ça reste assez anecdotique.

Je ne surestime rien. L'encapsulation limite la modularité parce que son utilité est justement de retreindre l'accès aux données et de leurs manipulation à des méthodes définies au niveau de la classe. Une classe qui voit plusieurs de ces instances encapsulées dans d'autres classes peut poser des problèmes à la modification. Pour le coté anecdotique, je suis d'accord mais la on discute théorie alors je me lâche un peu.
La modularité relève de choix architecturaux qu'il faudrait faire idéalement en fonction du problème a résoudre et donc en amont du choix du paradigme du langage à adopter. En pratique, ces choix sont fait après et le paradigme du langage influe sur les choix architecturaux. La prise en compte des contraintes liées au langage passent donc implicitement avant la prise en compte du problème à solutionner.
En POO, il est question de concevoir les « boites noires » de façon à je jamais avoir besoin de les ouvrir, en relationnel il est question concevoir les relations que peuvent avoir les données entre elles, en procédural il est question de concevoir les sous taches qui devront traiter les données. Il n'est pas forcément judicieux de passer par un ORM pour squeezer le procédural parce que l'objet c'est la crème de la crème. Il n'est pas forcément judicieux d'instancier un objet unique qui ne fera que traiter du flux.

En revanche le fait de devoir passer par des closures pour masquer des informations, s'il s'agit bien d'encapsuler, me semble être autrement plus une source de complexité inutile.

L'utilité des closures n'est pas dans le masquage de l'information mais dans la possibilité de modifier une méthode associée a une structure comme on modifierait une vulgaire variable. La ou le comportement d'une instance est fixée par la classe modèle, le comportement d'une structure avec closure peut être modifié par l'affectation d'une nouvelle fonction. La structure une fois « instanciée » est complètement affranchie de son modèle et moyennant deux trois lignes de code, la structure affranchie peut elle même servir de constructeurs. C'était pour surtout pour la question de la modularité.

A mes yeux les bénéfices de l’encapsulation sont bien plus nombreux que les nuisances. De plus, c’est un peu comme avec les Legos, si tu ressens le besoin de scier des briques pour que ta création ressemble à quelque chose, même si c’est tentant ça signifie surtout qu’il y a un souci d’analyse quelque part.

Je ne parle pas de nuisance mais de contraintes liées aux caractéristiques du langage. Les contraintes ne sont pas nuisibles. Elles sont même souvent un gage de cohérence et de sécurité. Seulement l'ajout de contrainte se fait souvent au détriment de la modularité.
Celui qui a créé les briques du legos n'a tout simplement aucune idée du type de besoin auquel les futurs utilisateurs des briques vont devoir répondre. Il n'est déjà pas évident pour le concepteur des briques de connaitre l'utilisation qu'il en fera dans le futur.
Une analyse, même très bonne, ne peut se faire qu'a partir des éléments que l'on prend on considération. Nul n'est omniscient.

Je vais caricaturer un peu mais c'est pour l'exemple.
Dans le cas de la classe « véhicule », la propriété « nombre de porte » est tout simplement en trop pour la classe « moto ». Si pour une raison quelconque on décide de créer les classes « vélo » et « char à voile », c'est la propriété réservoir qui est en trop. Si on veut rester dans le paradigme objet, il faut créer les classes intermédiaires « véhicule a porte » « véhicule à réservoir », envisager l'héritage multiple pour recycler un maximum l'existant puis penser à mettre à jour l'ensemble des classes qui héritaient de véhicule.
Il faut également espérer qu'un autre développeur n'ai pas l'idée d'emmener un vélo à la station service parce que l'interface existe et selon la manière dont le test d’arrêt est fait, ça peut être la catastrophe.
La POO est un modèle d'organisation du code mais il n’empêche pas les erreurs de conceptions.

L’encapsulation ne doit pas être vue comme un carcan mais, justement, comme un moyen d’organiser/structurer son code pour être manipulable en toute sécurité (surtout lorsqu’on bosse en équipe, chacun sur un pan métier différent par exemple).

C'est ce que j'entendais en disant que l'avantage de la POO est avant tout normative. La POO propose une norme de travail la ou le procédural en impose moins mais la liberté de respecter ou non les normes existantes ou de s'en imposer reviendra toujours au dev (au risque et péril de sa carrière professionnelle en cas de non respect, cela va sans dire).

On peut faire du structuré en procédural (encore heureux), mais pas autant qu’en OO de mon point de vue (du moins pas comme je l’entends ; structuré == organisé && sécurisé).

C'est la ou vous vous trompez mais ce n'est pas de votre faute, la POO est vendue comme cela.
La sécurité, la structure ou l'organisation du code dépend de bonnes pratiques transverses non lié au langage lui même. Ainsi un dev averti privilégiera l'utilisation de bibliothèques éprouvées aussi bien en objet qu'en procédural. On évitera que le junior bidouille du code critique en prenant soin de le mettre dans un fichier à part et on mettra à sa disposition une interface sûre. L'OO ne fera jamais le boulot d'un bon architecte, loin s'en faut.
On vous a appris ces méthodes en même temps que la POO, sans vous dire que l'équivalent existait ailleurs, si bien que vous n'arrivez pas à dissocier les deux. La sécurité peut se diviser en plusieurs aspects biens distincts : la protection vis à vis de l'extérieur, qui regroupe les question de l'authentification de l'utilisateur, le contrôle des entrées, la protection vis à vis des autres développeurs, avec les tests de non régression et le classement du code en fonction de leur criticité et le contrôle de leur modification, la protection plus architecturale concernant les détails liées aux signaux, accès concurrent, ramasse miette gestion des erreurs, gestion de l'absence de réponse, famine, deadlock, etc. Ces aspects ne sont pas liés à la POO. Ils seront géré d'une façon en POO et d'une autre en procédural.

Un dev procédural au fait de ces aspects et qui maîtrise ces notions fera d'avantage dans le structuré et le sécurisé qu'un dev objet qui ne les connait pas, quand bien même le dev objet est un bon dev objet maîtrisant les notions d'héritages, de polymorphisme, de généricité et autre sur le bout des doigts.

[RyzenOC]

Pour faire du code modulaire, le mieux je pense c'est un code orienté objet avec des interfaces.

Un truc que je vois souvent et qui m'énerve, pourquoi personne n'utilise d'énumération et à la place stock les infos "statique" dans des tableaux ?

[Luc Hermitte]

Des définitions d'objet il n'en manque pas. Des liens sur le vénérable site de référence sur le sujet ont déjà été donnés: http://www.c2.com/cgi/wiki?DefinitionsForOo
J'aime bien les définitions de Kay

<OOP means to me only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things>

[A noter que le polémique Kay excluait de la liste des LOO C++ et Java tandis qu'un de ses préférés était fonctionnel et non procédural (CLOS)]
et aussi la définition de de Cook:

<An object is a first-class, dynamically dispatched behavior.
A behavior is a collection of named operations that can be invoked by clients where the operations may share additional hidden details. Dynamic dispatch means that different
objects can implement the same operation name(s) in different ways, so the specific operation to be invoked must come from the object identified in the client's request. First class means that objects have the same capabilities as other kinds of values, including being passed to operations or returned as the result of an operation. A language or system is object oriented if it supports the dynamic creation and use of objects. Support means that objects are easy to define and use. It is possible to encode objects in C or Haskell, but an encoding is not support.>

Est-ce que tout cela est exploitable directement ? Pas vraiment. On est loin de la vulgarisation.
On peut noter que ce qui compte avant tout, c'est la behavioural abstractions et non pas la structuration des informations -- on est loin des exos classiques, que je qualifierai de Bases de Données, où l'on apprend à modéliser les relations dans une bibliothèque ou une pharmacie. Autres aspects extrêmement importants dans ces définitions : l'ultra-dynamisme, ou encore le tout objet.

Bref. Quand je l'explique je me rattache à ces choses.

L'abstraction
C'est le premier élément important. Et il n'est pas propre à la POO. Cook a un papier où il pinaille furieusement quant à la différence entre abstraction des TAD et celle des objets. En C++, je ne vous le cache pas, c'est tout pareil pour moi.

Bref, l'abstraction, on connait. C'est très bien présenté par Jobs dans son exemple. (NB: Il parle aussi des messages qui aboutissent à provoquer les actions qui vont bien)
L'exemple usuel que je prend en général, c'est celui de la laverie (en mode control freak et orienté données), VS le pressing (on est dans le pur service).
Ma vision aujourd'hui, est qu'abstraction et data hiding vont main dans la main.

Et ce sont des choses très proches de l'encapsulation, et pourtant subtilement différentes. La faute à mon avis au modèle des visibilités apparu avec le C++.
Avec abstraction/data-hiding, on cherche à définir des interfaces stables et pérennes. Robustes aussi? donc point suivant.

L'encapsulation
Cacher les données n'est pas la finalité. D'ailleurs Eiffel ne cache pas, et Python le fait juste par convention.
L'objectif est de garantir les invariants des objets.
L'invariant le plus fondamental de tout objet est: "est utilisable, dans un état pertinent, ..."
Il peut y avoir d'autres invariants: une liste triée sera triée (invariant visible). Un nombre rationnel pourra être implémenté avec un dénominateur strictement positif, et PGCD(num,den)==1 : des invariants détails (je suis sûr qu'il y a un terme officiel pour ça)

Mon exemple: Le voisin a une panne de machine à laver, on veut bien lui donner accès à celle de la buanderie. Seulement, attention le chat de la maison est un drogué qui ne rêve que de détergents et autres produits qui lui seront nocifs. L'invariant de la maison : la porte de la buanderie doit toujours être fermée à peine on traverse.
Si on peut faire confiance au voisin pour la refermer dans une utilisation nominale de ce à quoi on lui donne accès, peut-on toujours lui faire confiance en cas de situation exceptionnelle (p.ex. l'école appelle, il est arrivé un soucis au fiston) ? Rien n'est moins sûr.

Et on retombe sur messages et abstraction: on oblige à passer par une interface dédiée qui permet de garder la cohérence de l'état interne: dit autrement, de garantir les invariants.

L'import de code
C'est la réutilisation vendue par les marketeux OO des 80's comme un truc génial de l'OO. Sauf que l'on savait déjà faire des fonctions et composer des structures avant.
Cela se traduit par l'héritage généralement. Parfois des modules. Le C++ a même un héritage qui ne fait que importer : l'héritage privé
Ca peut être utile, mais ce n'est pas important.
C'est le truc qui AMA a été abusé dans des exos et autres cours d'initiation. Truc, qui AMA toujours, détourne de la compréhension du monde OO.

Le sous-typage.
aka polymorphisme, dit d'inclusion (avec C++ & cie), et qui a la particularité d'être dynamique. Je ne serai pas trop ranger python et autres langages à polymorphisme paramétrique & duck-typing dans l'affaire. La notion chapeau n'est peut-être pas le sous-typage. Je ne saurai pas dire. Sans parler du double dispatch que l'on a avec CLOS, COS, et avec divers frameworks qui l'émulent dans plein de langages.

Comment je présente ça? Je reviens à la problématique chapeau : une procédure commune relativement abstraite (au sens "pas spécialisée") dans laquelle il y a des points de variation -- cas particulier de l'OO, les points de variations sont dynamiques. Techniquement mon exemple est une transposition de l'OCP (principe ouvert fermé) :
On veut dépoussiérer le sol: on sort donc l'appareil qui va bien de son lieu de stockage, on s'assure qu'il est fonctionnel, on parcours la pièce pour collecter poussière et autres saletés, et à la fin, on vide la poussière collectée avant de re-ranger l'appareil à sa place.
Que l'appareil soit un balai, un aspirateur, ... on ne fait que spécialiser le comportement aux points de variations. Et si on doit rajouter un nouvel appareil, on ne veut pas aller taper dans la procédure pour modifier 50 if, mais on veut que le nouvel appareil (aspirateur centralisé, ou sans sac, ...) soit plug and play

Mon exigence est de retrouver l'OCP. Et par ce biais j'introduis le polymorphisme d'inclusion dynamique du monde OO.

Ceci est à mon avis le plus gros intérêt de l'OO.

À noter que le sous-typage se fait techniquement avec l'héritage dans nos langages. Et que Java offre un héritage qui ne permet que de sous-typer : l'héritage d'interface.

[DonQuiche]

En POO, il est question de concevoir les « boites noires » de façon à je jamais avoir besoin de les ouvrir, en relationnel il est question concevoir les relations que peuvent avoir les données entre elles, en procédural il est question de concevoir les sous taches qui devront traiter les données. Il n'est pas forcément judicieux de passer par un ORM pour squeezer le procédural parce que l'objet c'est la crème de la crème. Il n'est pas forcément judicieux d'instancier un objet unique qui ne fera que traiter du flux.

A vrai dire même dans un langage objet je préfère rester au plus proche de la logique du SGBD pour interagir avec celui-ci. Je ne suis pas fan des active record & co en général.

Mais ce n'est pas une question liée à la POO, c'est lié à l'interaction avec un paradigme étranger.

Celui qui a créé les briques du legos n'a tout simplement aucune idée du type de besoin auquel les futurs utilisateurs des briques vont devoir répondre. Il n'est déjà pas évident pour le concepteur des briques de connaitre l'utilisation qu'il en fera dans le futur.

Je ne pense pas qu'il suffise d'exposer les détails de l'implémentation pour créer un design modulaire et universellement adaptable. Pour moi contourner l'encapsulation n'est qu’exceptionnellement utile.

En revanche le typage nominal et le fait d'imposer des types précis, et donc d'interdire des types utilisateur lors de l'appel des méthodes, est la raison essentielle qui limite la modularité en POO. Mais c'est le prix à payer pour la lisibilité et la maintenabilité (dans le sens où il es plus facile de modifier un objet pour y aouter une information que de modifier mille fonctions pour diffuser cette nouvelle donnée partout). En partie du moins : dans les langages récents on observe une convergence du typage faux-dynamique et statique (via l'inférence), structurel et nominal.

[psykokarl]

Mais ce n'est pas une question liée à la POO, c'est lié à l'interaction avec un paradigme étranger.

De votre point de vu sans doute, car vos choix architecturaux s'accommodent de l'OO dans le but de modifier le comportement du système. Du point de vu des concepteurs du SGBD, le but est de fournir un langage qui permet de d'enregistrer et de retourner des jeux de données les plus divers possible sans qu'il soit nécessaire pour le développeur de modifier le comportement du système. Les SGBDO existent et ont eu le succès qu'ils ont. Rien n’empêche de concevoir un SGBDR en OO.

Je ne pense pas qu'il suffise d'exposer les détails de l'implémentation pour créer un design modulaire et universellement adaptable. Pour moi contourner l'encapsulation n'est qu’exceptionnellement utile.

Je n'ai pas dit cela. La modularité d'un design relèvent des choix architecturaux pris en amont. Exposer les détails de l'implémentation d'une classe est inutile dès lors qu'elle peut être considérée comme atomique, autant pour des raisons de criticité ou de simplicité de son implémentation.

[Luckyluke34]

Je trouve que la définition de Steve Jobs va très bien aussi à la programmation procédurale.

Donc je ne suis pas le seul à penser cela.

Vu que apparaement personne n'arrive à avoir une définition plus claire et ciblé de ce que permet vraiment l'objet, je m'en vais apprendre la POO pour me forger ma propre opinion.

Pourtant on vous a démontré par A plus B que des mots-clés très importants dans l'explication de Jobs étaient totalement en-dehors du monde de la programmation procédurale :

mémoire à l’intérieur d’eux
se souvenir des choses
envoyer un message
encapsuler

Maintenant on parle d'un paradigme dont l'étude fait souvent l'objet d'un semestre universitaire entier voire plus. Donc évidemment qu'on ne peut pas le résumer en quelques phrases, même si l'explication de Jobs en brosse un portrait à grands traits. Evidemment qu'il faut chercher la connaissance à la source pour comprendre tous les concepts.

[Kapeutini]

Je ne suis pas depuis longtemps en POO mais j'en ai compris qu'on pouvait rendre le code plus souple par plus d'abstraction et d'héritage et mieux représenter et s'interfacer avec le monde
mais je rêve de classes vivantes ...intelligentes des sortes de nano machines qui s'articuleraient ensemble selon une logique issue de l'humain
donnant de plus en plus d'autonomie aux machines pour les détails :-) qu'elle aurait tout loisir d'améliorer selon son expérience ou les expériences partagées

[Sve@r]

Comment pourriez-vous expliquer l'orienté objet ?

Je pourrais l'expliquer de façon claire et concise tout en restant simple et pragmatique

[Jitou]

Je connais beaucoup de personnes qui sont vendeurs à la base, MOA ou expert métier et qui savent très bien expliquer des concepts techniques des plus simple ou plus ardus. Et puis ce n'est pas nouveau se sont les développeurs qui ont le plus de mal à communiquer sur leur "science".