C'est totalement stupide de changer comme ça de fonctionnement ! Je ne comprend absolument rien a la programmation orientée objet, avec la programmation procédurale il y avais du sens, de la logique, c'est facilement compréhensible. mais putain dès que je vois un programme avec des objets c'est comme si j’étais un trisomique devant un livre traitant de la complexité de la physique quantique dans un contexte contemporains.

C'est le bazars total, ce n'est pas basé sur un modele logique, pour comprendre un minimum il faut se taper absolument tout le prgramme ou rentrer dans la tete de celui qui l'a conçue

BREF FUCK !

? Troll ?

- Tu peux faire de l'objet avec du procédural.

- Si t'as compris le principe des structures, t'as compris grosso-modo le concept de base de la POO

Salut,

C'est clair que le passage à la POO c'est une remise en question totale, et d'ailleurs beaucoup de font jamais le pas. Tu peu essayer quelques cours fondamentaux, il y en à ici par exemple : http://general.developpez.com/cours/#generalite

Ensuite toujours la même recette : commencer par programmer toi même de petits exemples simple.

Pour moi c'est quasiment la même chose, dans le sens ou je comprend pas la finalité de programmer "en objet". ça viendra surement plus tard qui sait, mais pour l'instant je peut largement m'en passer

Je ne trouve pas que les 2 choses n'ont rien à voir.
Dans les 2 cas on recherche l'encapsulation, on regroupe les données et on expose les fonctions qui permettent de travailler dessus sous une interface de plus haut niveau.

La façon de réfléchir en elle-même est pas extrêmement différente de mon sentiment.

Quand il est bien utilisé, le paradigme objet permet généralement de:
-"Sécuriser" ce qu'on conçoit, dans l'optique de le faire utiliser à d'autres personnes (càd que même en partant du principe que l'utilisateur est con, si l'objet est bien "ficelé", il peut s'assurer "lui-même" de sa propre intégrité)
-Se rapprocher un peu plus du "monde réel" quand on modélise les choses. (qu'il s'agisse des inté$eractions -objet A envoie un message à objet B, etc.- ou encore des relations d'héritage ("Une voiture est une sorte de véhicule, donc la classe Voiture hérite de Véhicule"...)
-Simplifier un peu les choses, en réunissant proprement les données, et le code qui est censé les traiter

Pour nous introduire à l'orienté objet, notre professeur a commencé par nous pousser jusqu'aux limites du procédural (en C), en nous demandant d'implémenter, de la manière la plus "jolie" et "futée" possible, un modèle de nombres complexes.
Petit à petit, d'amélioration en amélioration, nous avons commencé à "voir" les concepts de l'objet, sans même utiliser un langage objet: en soi, on peut faire de l'objet en C, mais la syntaxe devient vite infâme, et les langages "orientés objet" ont des fonctionnalités très pratiques qui allègent pas mal le code de ce point de vue là (sans parler des "bonus", qui ne sont vraiment pas utilisables dans un langage procédural, je pense).

Donc oui, essaie d'implémenter un truc en apparence aussi simple que "les nombres complexes" en C, de manière à pouvoir redistribuer ton code au premier des abrutis, et qu'il soit incapable de "corrompre" un nombre complexe en faisant des idioties avec.
Réfléchis aussi aux intérêts des notions comme le polymorphisme, ça aussi c'est assez casse-burnes à mettre en place dans un langage comme le C, alors que ça devient très simple (et intéressant à exploiter) dans des langages orientés objet.

" le paradigme objet permet généralement de:
- Sécuriser [...] "
faux, c'est l'abstraction de type qui permet de faire ce que tu dis. Et on peut le faire en C sans soucis.

" - Se rapprocher un peu plus du "monde réel"
question de point de vue et de contexte. Là, j'attire juste ton attention sur le fait que ton première exemple relève plus de la programmation événementielle que de la programmation orientée objet.

" - Simplifier un peu les choses, en réunissant proprement les données, et le code qui est censé les traiter "
Les modules (~= fichiers .c séparés) permettent de cloisonner tout aussi bien.

Kaops : si tu ne vois pas l'intérêt de la programmation orientée objet, ne l'utilise pas et puis c'est tout. Tu peux tout faire sans, de toute façon.

J'ai pas compris l'utilité et la defition de la POO

je pense que le succes de la poo est du à sa relative simplicité

"C'est pratique pour faire des programmes plus durables" Faux. Encore une fois,
c'est l'abstraction de type qui permet de masquer le code d'une bibliothèque (et donc de rendre la bibliothèque réutilisable).

Je vais tenter d'expliquer un peu en reprenant une explication que j'avait vu dans un livre :

Prenons l'exemple d'une voiture dans la vie réelle:
Une voiture possede des attributs (une couleur, une vitesse, etc... )
Une voiture peut par exemple avancer (modifier sa position )

tu par exemple représenter ça en POO avec une classe voiture ayant les attributs couleur, vitesse, position etc.. et une fonction avancer qui modifie la position de la voiture.

Tu peux ensuite avec ta classe créer par exemple une voiture grise et lente ou une voiture rouge et rapide (par exemple). Et les faire avancer quand tu le souhaite avec ta fonction qui s'occupe de changer la position de ces voitures en fonction de leur vitesse.

Ensuite comme dans la vie réelle, tes voitures peuvent interagir avec d'autres objets.
Par exemple une voiture peut se crasher contre une autre voiture
ou bien encore recharger son essence si un "objet" station essence est à proximiter (tu peux par exemple representer ca par une fonction de l'objet station que tu appele par exemple quand la voiture n'a plus beacoup d'essence qui tout d'abord teste si l'objet voiture est à proximité et recharge l'essence de cette voiture si c'est le cas

Ensuite pour l'héritage, il faut voir les objets en differents niveau d'abstraction.
par exemple une voiture et un char d'assault sont tout deux des engins roulants (qui ont comme points commun de pouvoir avancer, d'avoir des roues et une couleur) mais le fait de pouvoir tirer est propre au char.

en esperant que mes explications t'aident à y voir plus clair

Tu apprends et tu fermes ta gueule. Comme ça que j'ai réussi dans ce domaine

On s'adapte avec son temps
La POO c'est souvent plus intéressant et ça permet de trier les fonctions en plus
T'es pas obligé d'utiliser toutes les fonctionnaités du POO mais dès que tu sais la base tu peux organiser les instructions de façon utile et efficace pour rendre ton script plus beau en terme de lisibilité !

Si je devais sortir les avantages de la POO, je pense que je parlerais de la réutilisabilité du code au travers de l'héritage, et du polymorphisme qui apporte quelques propriétés intéressantes au typage, et *peut* donc contourner certaines restrictions du typage fort pas toujours pratiques.
La combinaison des deux me semble ainsi plus performante que la composition (struct Y; struct X {struct Y y;};), quand on veut réutiliser du code, parce que ça implique moins de code à écrire pour faire la même chose, et au travers d'une interface unifiée. (Et ce, sans passer par des f*cking templates. )

Paradoxalement, le code que tu utilises le plus doit être celui de "printf/echo/println", que tu extrais du module standard de ton langage de programmation préféré.

De fait, l'héritage seul n'apporte pas grand chose je trouve. Couplé au polymorphisme obtenu grâce aux classes abstraites, ça devient par contre très intéressant et utile.

Les interfaces, l'héritage, les singletons, les mapping objets-relationnels...

Y a pleins de choses qui découlent de la POO très utiles pour structurer un projet et pouvoir dans certains cas le rendre plus évolutif, plus facilement maintenable, plus structuré pour la compréhension de ce dernier etc...

Sauf que les interfaces et le mapping relationel->code ne sont absolument pas propres à la POO (oserais-tu prétendre qu'il n'existait pas de code évolué ni de bibliothèques avant la démocratisation de la POO ? ).

Et au risque de me répéter, la POO n'apporte pas de gain ni dans la structure du code, ni dans sa maintenabilité, ni dans sa réutilisabilité.

La seule chose vraie que tu dis, c'est que la POO apporte une certaine évolutivité.

"Et au risque de me répéter, la POO n'apporte pas de gain ni dans la structure du code, ni dans sa maintenabilité, ni dans sa réutilisabilité. "

On peut faire tout ça avec des langages non orientés objet. Mais c'est quand même carrément plus pratique avec la POO.
D'ailleurs ça me paraît bizarre de dire que l'évolutivité apportée par la POO ne rend pas le code plus maintenable : l'évolutivité est une composante de la maintenabilité.
Et puis, les templates ou generics qu'on retrouve dans les langages orientés objets, ça favorise pas la ré-utilisabilité ?
Quant à la structure du code, c'est plus subjectif, mais n'importe qui utilisant régulièrement un langage orienté objet tendra à affirmer que le code est plus structuré en POO. UML ou les designs patterns ça aide pas mal.

Actuellement les entreprises sont extrêmement préoccupées par toutes ces contraintes de maintenabilité et ré-utilisabilité, et si les langages orientés objets sont massivement populaires, c'est pas par effet de mode mais c'est parce que ça satisfait un réel besoin. Et en travaillant régulièrement avec on en constate tous les jours les bénéfices : je le répète, ça ne permet pas de faire plus qu'avec un langage non OO, mais ça offre des outils qui structurent et simplifient l'écriture du code.

D'ailleurs est-il possible d'implémenter proprement dans une bibliohtèque les principaux designs patterns utilisés en entreprise sans utiliser la POO ? Pour le pattern listener par exemple ou le pattern MVC ?

"On peut faire tout ça avec des langages non orientés objet. Mais c'est quand même carrément plus pratique avec la POO. " dans la mesure où un code en POO est environ 4 fois plus long que son équivalent en fonctionnel, j'ai envie de dire que non. Après, ma conception du code facile à lire, à développer et à maintenir implique que le code doit être le plus court possible. Bien évidemment, quelqu'un qui a fait de la POO toute sa vie aura une conception différente. Mais il ne faut pas confondre la facilité apportée par l'expérience avec celle qu'apporte (ou pas, ici) une technologie ou un concept.

"D'ailleurs ça me paraît bizarre de dire que l'évolutivité apportée par la POO ne rend pas le code plus maintenable :" heu... d'après le TLFI :

Maintenir = Faire rester quelqu'un, quelque chose dans une position, une situation données.

Evoluer = Se transformer par étapes successives, passer progressivement d'un état à un autre.

Ces deux choses sont opposés. Et comme je l'ai dit, l'apport de la POO, c'est la possibilité d'évolution/d'extension du code.

"Et puis, les templates ou generics qu'on retrouve dans les langages orientés objets, ça favorise pas la ré-utilisabilité ? " non, car c'est une version médiocre du vrai polymorphisme que on trouve dans des tas de langages. Par ailleurs, du point de vue de la théorie des types, ceci n'a rien à voir avec la POO.

"UML" tu peux toujours t'appuyer sur des outils de genre UML pour organiser ton code, mais si celui-ci sera "juste" codé avec des modules. C'est une mauvaise interprétation de croire que ces outils de conceptions de code sont là uniquement pour faire de la POO.

"les design patterns" J'ai deux définitions pour les design patterns :
1. astuce pour résoudre un problème technique complexe en POO.
2. technique utilisée par un ingénieur pour résoudre un problème tout en évitant d'analyser exactement ce problème.

Pour le 1., il y a des astuces dans à peu près tous les langages, et pour tous les types de programmation. Et pour le 2, je n'appelle pas ça de la programmation.

En vrai, les autres paradigmes apportent leurs propres problèmes et solutions. La question n'est donc pas tant de savoir si je pourrais faire du design pattern (on s'en fout de savoir qui a la plus grosse ... connaissance dans les design patterns ) mais de décider du paradigme qui permet de programmer l'application souhaité de la façon la plus satisfaisante. Et là, la réponse en entreprise est : avec la POO, on ne sait faire que ça.

Dans l'absolu, la POO est cependant rarement la meilleure solution de façon évidente.