En mon sens
Pour ta question technique : je dirai que PHP a la fin du script appel automatiquement le destructeur.

Donc forcement si ton code est ultra-mega long ca peut ne pas faire de mal , pour alleger le serveur.

Et pour ta question de point de vue , c'est une question d'habitude.

Personnellement je trouve que c'est plus lisible du POO que tu Procedural.
Je trouve le POO plus maintenable que le Procedural
Mais le POO est plus long a concevoir =)


Bonne aprem Hawk

Alors pour la question de technique:
-j'ai lu sur des forums que les destructeurs n'étaient pas très utile en php. Or je sais que les destructeurs permettent de libérer de la mémoire en détruisant les objets utilisés. Donc je voulaiss avoir si c'était bien ou pas.

Les destructeurs permettent de libérer des ressources. La libération de mémoire c'est un cas particulier de la libération de ressources. En PHP, la mémoire est gérée automatiquement par l'interpréteur, il n'y a pas à la libérer.
Mais comme je disais, la libération de mémoire est un cas particulier, tu peux avoir d'autres ressources à libérer (connexion à des bases de données, fichiers, etc). Dans ce cas les destructeurs sont primordiaux. Après c'est vrai que c'est rare, on pourrait même se passer de libérer certaines ressources. Mais ils sont utiles dans certains cas.

Alors pour la question de point de vue:
J'aime pas trop le php procédural mais l'utilisant en stage, je voulais savoir si c'était bien de coder des sites en procédural. Pour ma part je pense que maintenir du code en procédural ca tourne vite au bordel.

Ya pas de bien ou mal.
Le procédural c'est réputé pour s'optimiser plus que de l'objet, mais pour être immaintenable. Et à savoir que pour la performance, on ne fait pas ses sites en PHP mais en C. Donc en l'occurrence il y a rarement de justification pour bannir les objets en effet.

Hey ,

Désolé de vous déranger mais j'ai deux questions:

Meeerde, il nous pose une question, on est obligé de répondre .
Non mais sans blague, tu ne nous déranges pas une seconde . On est là pour t'aider.

j'ai lu sur des forums que les destructeurs n'étaient pas très utile en php. Or je sais que les destructeurs permettent de libérer de la mémoire en détruisant les objets utilisés. Donc je voulaiss avoir si c'était bien ou pas.

Bah c'est archi-faux.
Tous les objets en PHP ont un destructeur par défaut. Ce destructeur sert à libérer la mémoire de l'objet, comprendre de ses attributs.
Si on déclare notre propre destructeur, il sera appelé avant le destructeur par défaut. On peut s'en servir pour fermer une connexion vers une base de données, déverrouiller des fichiers (si on a posé des verrous dessus), faire des manipulations de dernières minutes etc. Même si PHP gère la plupart de ces choses tout seul, il est parfois bon de le forcer.
On peut également avoir besoin de supprimer un objet manuellement. Dans ce cas, on utilise unset() qui va appeler le destructeur (si déclaré) puis celui par défaut (natif à PHP). On peut également mettre la variable qui contient notre objet à null et on laisse bosser le garbage collector mais bon …

J'aime pas trop le php procédural mais l'utilisant en stage, je voulais savoir si c'était bien de coder des sites en procédural. Pour ma part je pense que maintenir du code en procédural ca tourne vite au bordel.

Le PHP est multi-paradigme, car il est procédural, fonctionnel (complètement depuis la 5.3) et orienté objet (au passage, on dit la POO, et non pas le POO, car c'est la programmation orientée objet … hein TheHawk ). Il gère très bien tous ses paradigmes. À toi de t'organiser en fonction de ton projet et de tes besoins, car chaque paradigme répond à un besoin particulier.

Normalement plus le projet est gros plus l'utilité de l'objet se fait ressentir.

Après niveau maintenance, je pense qu'un code peut vite se bordeliser en procedural comme en objet, et que quelque soit l'option choisie, faut tjs faire attention à ce qu'on fait et reflechir à la manière dont cela peut évoluer.

après c'est aussi une question de gôut.
Mais de nos jours, il vaut mieux être familiarisé avec la POO parce que pas mal de classes utilies comme celles de FPDF, EZPDF, JPGRAPH, ARTICHOW... sont codées en objet.

Comme déjà dit plus haut il n'y a pas de bien ou de mal.

Si tu dois passer trois fois plus de temps pour développer en poo un script trop particulier pour qu'il puisse te resservir ailleurs, l'intérêt de la poo n'est pas évident, sauf peut être celui de la maintenance s'il s'agit d'un script important.

Encore qu'avec un peu d'organisation on peut faire du procédural qui puisse permettre une maintenance acceptable en regroupant certains paramètres dans des fonctions...

Et puis, rien n'interdit d'utiliser conjointement les deux.

D'une manière générale pour du sur mesure, l'intérêt de la poo est évidente pour un gros site qui demande à évoluer souvent.
Cela l'est moins pour un "petit" ou "moyen" site qui n'évoluera que peu et dans ce cas je n'utilise que quelques classes génériques (sinon faudrait trois fois plus de temps pour un résultat identique).

C'est donc en fonction de tes besoins comme le disait HyWan.

Je suis juste moins d'accord avec ceux qui préconisent d'utiliser la poo systématiquement.

Outre le temps supplémentaire passé en développement, je me demande si pour un débutant ce n'est pas perdre de vue la "philosophie" de la poo et prendre de mauvaises habitudes en faisant du code qui n'aura de poo que le nom des classes.

Si tu dois passer trois fois plus de temps pour développer en poo un script trop particulier pour qu'il puisse te resservir ailleurs, l'intérêt de la poo n'est pas évident, sauf peut être celui de la maintenance s'il s'agit d'un script important.

Ah oui, en effet.
Pour du scripting pur, c'est très efficace le procédural, puisque c'est orienté algorithme, donc c'est plus facile à appréhender.
Pour de l'intégration aussi, donc pour lier des logiciels ensemble ou bien un logiciel à un système.

L'objet est en général plus important dans des programmes où les données devront être réutilisées, où elles ont une organisation intrinsèque (Les menus contiennent des liens, les pages contiennent des titres).
L'objet est lui orienté données. Un objet te permet de représenter une entité complexe, et tu organises naturellement tes traitements autour de ces objets.

Voilà, ce sont deux visions. Une vision algorithmes et une vision données, sauf qu'en général, pour un site, c'est la vision données qui est largement prohéminente.

La conception objet oblige à abstraire notre problème, ce qui n'est pas toujours possible, notamment avec le déploiement d'algorithme. Je voulais juste redire ce que Sékil' a dit, mais en utilisant le terme « abstraire », car c'est très important dans le paradigme objet. Si on ne sait pas abstraire, on ne fait pas d'objet, c'est tout. Car je vois trop souvent des gens qui placent leur fonction dans un objet et disent : « Ça y est, je fais de l'objet ». Pas du tout, c'est complètement faux.

Hello,

...
Si on ne sait pas abstraire, on ne fait pas d'objet, c'est tout.

Je ne suis pas tout à fait d'accord sur cela. Je crois que c'est en persévérant que l'on y arrive, n'est ce pas ? Cependant, il est raisonnable d'apprendre et par la suite d'écrire suivant les bonnes pratiques.

Car je vois trop souvent des gens qui placent leur fonction dans un objet et disent : « Ça y est, je fais de l'objet ». Pas du tout, c'est complètement faux.

Exact ! Bien que je sois loin d'être un expert, j'ai remarqué que beaucoup font des confusions d'écriture. Si je ne m'abuse, les attributs et les méthodes sont propres à l'objet et beaucoup ne comprennent pas cette notion.

Évidemment qu'il faut apprendre, je ne dis pas le contraire …

Et pour les gens qui mettent toutes leurs fonctions dans une classe, le problème est qu'on perd la notion de réutilisabilité et de modularité. C'est un gros bazard qui ne sert à pas grand chose au final.

Évidemment qu'il faut apprendre, je ne dis pas le contraire …

Et pour les gens qui mettent toutes leurs fonctions dans une classe, le problème est qu'on perd la notion de réutilisabilité et de modularité. C'est un gros bazard qui ne sert à pas grand chose au final.

Ouais mais c'est comme ça qu'on apprend.

Ma première classe, c'était un merdier monstre inutilisable.
Ensuite j'ai compris que les objets pouvaient interagir entre eux, et que faire une classe c'était pas faire de l'objet.
Ensuite j'ai compris comment faire interagir mes objets ...

Bref, faut de toute manière merder pour comprendre l'objet.

Je ne parle pas des gens qui apprennent mais des gens qui mettent tout et n'importe quoi dans une classe .

Je ne parle pas des gens qui apprennent mais des gens qui mettent tout et n'importe quoi dans une classe .

C'est exactement ce que je faisais quand j'apprenais ^^

mais je comprends ton raisonnement. Ce que je dis, c'est qu'il faut mettre tout et n'importe quoi dans une classe pour s'apercevoir que c'est une boulette en fait.

Après quand on recommence, là ...

Sur ce point la je pense qu'il faut voir la classe comme une boite, ou chaque outil est complémentaire et a un lien avec un autre.
C'est comme si dans une boite a outils nous avions un marteau et une vis, pas très utile l'un avec l'autre non ?
Ne pas mélanger les serviettes et les torchons comme l'on dit je crois non ?

Sur ce point la je pense qu'il faut voir la classe comme une boite, ou chaque outil est complémentaire et a un lien avec un autre.
C'est comme si dans une boite a outils nous avions un marteau et une vis, pas très utile l'un avec l'autre non ?
Ne pas mélanger les serviettes et les torchons comme l'on dit je crois non ?

Pour continuer dans cette image, je dirais que le clou et le marteau ne doivent pas se trouver dans la même boite à outils, mais dans 2 boites.
Ensuite, que l'on fasse appel au marteau pour utiliser le clou, c'est l'interaction entre classes.

Mais ce n'est pas parce qu'on utilise le clou et le marteau au même moment qu'ils doivent se retrouver dans la même classe