Voila mon problème, je vois tout a fais l'utilité de la programmation objet en C, en delphi ou tout autre langage, sauf justement pour le web. je m'explique, l'objet meurt dés que la page est chargé, et même en faisant de l'ajax, il faut quand même a chaque appel recréé l'instance et réattribués les valeur des attributs. Je ne vois donc pas de différence avec de la prog fonctionnelle classique.
Donc hormis le fait de structurer mieux, je trouve ça encore plus lourd que la fonctionnelle à utiliser.

Ca ce sont mes conclusions de vieux briscard, qui a du mal à saisir les abstractions, j'aimerais être détrompé, si quelqu'un pouvait éclairer ma lanterne

Même si l'objet meurt après quelques dixièmes de secondes, le code a souvent le temps, pour des applications importantes, de faire des milliers d'opérations.
L'utilité de l'objet n'est pas tant dans les performances, bien au contraire, la gestion de l'objet créera un code moins rapide qu'un code procédural optimisé. L'utilité principale se trouve au niveau de la maintenance du code, et de la facilité de développement.

Et c'est plus simple de comprendre sa structure...

Le C ne supporte pas la POO, le C++ oui...

Moi je ne comprennait pas l'utilité de la POO en PHP avant avoir fait un projet conséquent, regarde PHPBB, c'est de la POO...

Euh, quelle version ?

Je ne m'étais donc pas trompé dans mon analyse, ce n'est qu'une question de structuration, mais pas de performances. Ou alors, il faudrait tenté de faire un objet mixte php+javascript ou php+xmlhttprequest pour avoir la performance.
En fait j'utilise déjà abondamment XAJAX qui est une petite merveille, mais je ne vois pas bien comment y incorporer mes propres objets.

Le dernière en date...

Le dernière en date...

Oui bah c'est un peu une blague la POO dans phpBB3, ils ont fait des objets pour dire, "hé, regardez, nous aussi on fait des objets"…
Ils ont simplement mis leurs fonctions dans des objets, mais ils n'utilisent à aucun moment les avantages d'une architecture bien structurée comme la modularité, la facilité de maintenance, la réusabilité, etc…

Le C ne supporte pas la POO, le C++ oui...

Ce n'est pas si simple : le C ne connaît pas les classes mais on peut tout de même y faire de la POO.

J'en prends pour exemple le javascript par exemple est un langage totalement orienté objet, et pourtant lui non plus ne connaît pas les classes

Il ne faut pas associer aussi directement classes et POO. On peut avoir des classes sans POO et vice-versa

j'ai fais ça aussi à un moment, mettre des function dans une classes, mais finalement je n'y vois pas plus d'interet que d'écrire mes groupes de fonctions dans des fichiers séparés, hormis que c'est plus long à ecrire pour y avoir accès.

Bon si vous avez un exemple à me prêter...
Bref, Python aussi fait de la POO, si on va par là...
Mais, ce n'est pas le but principale du langage, en C faut inventer le roue pour avoir un système de POO complet et performant, pas en C++, ni en JAVA, ni en PHP aujourd'hui...
La POO et très peu utilisé en PHP car elle éxiste depuis peu et que la plupart des applications "à succès" sont anciennes donc avant l'avènement d'un système de POO efficasse, donc toutes les MAJ sont fait à la va comme je te pousse, d'ailleur avant on utilisait des fonctions en PHP, maintenant on commence à utiliser beaucoup d'objets (PDO, ZIP, etc.)...

Lä plus part des gros projet entammé en PHP aujourd'hui sont fait en POO...

Le C ne supporte pas la POO, le C++ oui...

Ce n'est pas si simple : le C ne connaît pas les classes mais on peut tout de même y faire de la POO.

+1, la POO, ce n'est pas une syntaxe de langage, c'est une façon de programmer (un paradigme de programmation).

Bonjour,
Si je puis me permettre, même si en PHP on parle de classes, d'objet et d'héritage, je ne suis pas forcément d'accord pour l'associer à POO.

La Programmation Orientée Object est un concept bien plus élaboré que ce que peut proposer PHP. La première évidence vient du fait du manque de typage de données, même si les dernières versions de PHP abordent mieux ce sujet, le typage reste très réduit.

On est tout de même loin de ce que peuvent proposer des langages comme C++ ou Java. PHP fait de l'objet comme peut en faire Javascript, c'est de l'assimilé objet, mais pas POO. Si on veut faire du POO pour le web, mieux vaut se tourner vers JSP (Java Server Page).

Donc, les classes en PHP sont surtout utilisables pour un confort de maintenance (un code mieux structuré), mais n'apporte pas la profondeur que l'on peut attendre d'un vrai langage objet.

Zecreator.

Le typage à été abolit à la création de PHP, il reste tout de même contrôlable, mais ça ne fait pas forcément partie de la POO...
Certes, l'héritage stricte est contrariant mais c'est quand même de la POO...

Hey ,

Pas mal de confusion par ici …
Javascript n'est pas du tout un langage orienté objet, c'est un langage orienté prototype. Attention, c'est différent. Certains se sont amusés à programmer des fonctionnalités de l'objet en Javascript, mais ce n'est pas toujours très pratique (et surtout pas fait pour). Attention à ne pas mélanger donc.

Concernant le C et le C++, le C++ n'est qu'une évolution. Il est entièrement bâtis sur du C. Ils ont ajouté quelques notions, mais que l'on peut déjà programmer en C. Le langage C est très très fort, et très puissant.

Ensuite, un langage 100% orienté objet, ce serait plutôt Java par exemple. On a en effet que des classes. En PHP, on est obligé de passer par une phase procédurale pour lancer notre architecture objet. Par exemple, on est obligé d'instancier le MVC dans un fichier d'amorçage (bootstrap) de façon procédurale pour lancer tout notre modèle objet.
Donc PHP n'est pas 100% objet, mais attention, il supporte très bien l'objet. On peut faire énormément de chose.
La force de PHP c'est son faible typpage, qui est aussi sa faiblesse. Si on programme comme il faut, on ne rencontre pas de soucis, mais c'est sûr qu'on peut faire n'importe quoi.
On parle d'héritage en PHP, mais on parle aussi d'interface, d'introspection, de classe abstraite, d'accès, d'association, d'agrégation, de composition, d'itérateur, de collection, etc. Tout ce que l'objet comprend en somme …
Et comme le dit Sékil et Calimero, la POO est un art de programmer, une façon de concevoir les choses, et pas une syntaxe. Je suis entièrement d'accord.

Le débat PHP vs JSP est éternelle. Il existe bon nombre de troll sur Internet, on va pas en recommencer un, merci.

À katagoto, en C, il ne faut pas réinventer la roue à chaque fois. C est un langage sur-puissant et il existe des tonnes d'outils. Comme tout langage très permissif (dans la manière de coder), il faut s'écrire ses propres bases, c'est normal.

En PHP, on utilise de plus en plus l'objet car l'objet est plus adapté à de gros projets. Les raisons principales sont la maintenance, la modularité, la réutilisabilité, la sécurité, etc., des applications, c'est normal.


Il ne faut pas faire de l'objet pour faire de l'objet comme je dis souvent. On fait de l'objet car il y a un besoin. Je déteste le fonctionnel et le procédural et j'adore l'objet, j'aime la philosophie. Après, c'est une approche. Si tu ne ressens pas le besoin de faire de l'objet, n'en fait pas. Mais tu verras que certains projets t'imposent l'objet d'eux-même.
A contrario, de problèmes ne peuvent se résoudrent qu'en procédural (voir le langage Prolog), car c'est une approche qui correspond beaucoup mieux.

L'objet sous PHP subit les inconvénients des limites de l'interprétation au détriment de la compilation mais le gain de performance se touche aussi dans l'organisation objet d'un programme par rapport au procédural. L'objet est une regroupement de références à des variables et fonctions pouvant être partagés par lien dynamique entre objets ou par héritage (lien statique) ce qui diminue les risques de redondances et favorise la réutilisation du savoir-faire.
L'objet sous PHP même s'il est au début de son périple, est sérialisable donc récupérable via les sessions ce qui permet de le garder en vie pour palier aux limites du pseudo client/serveur Web actuel.

Vous savez ce n'est PHP qui n'a pas le potentiel c'est son environnement Web qui pose des contraintes.