Procedural Ou Poo, nécessaire de se mettre à jour ?

Bonjour,

Après plusieurs années d'interruption de codage je repars sur un nouveau projet.

Le hic c'est que je connais surtout le PHP4 en mode procédural.
Et ça suffisait tout a fait pour faire mon jeu précédent (Guildes.jpc)

Aujourd'hui, tout le monde parle de php5 en POO et j'hésite à me "reformer" ou alors je continue en php4 procédural comme au bon vieux temps )

Vous en pensez quoi ?

Voici un très bon tuto pour ceux qui connaissant le php4 et pas la POO
http://www.siteduzero.com/tutoriel-3-14718...jet-en-php.html

.. mais bon, je ne demande toujours si ça vaut le coup de passer en POO

Sauf si vraiment les délais sont une containte et que l'apprentissage de la POO prend plus de temps que la réalisation du projet en procédural... a mon sens il est utille de passer sous ce paradigme, au moins rien que pour la culture générale

Cela permet d'avoir une modélisation objet de ses concepts, ce qui les rend plus facilement réutilisables/documentables/partageables, et ça rend plus facile l'utilisation d'un framework du quel partir ou l'intégration de modules existant pour s'éviter une bonne part de travail.
C'est peut-être un luxe pour un petit projet réalisé seul, mais ça devient vite une nécéssité pour un projet complexe ou en équipe.
D'autre part, une fois les principes acquis, ça permettra sans aucun doute d'augmenter la vitesse de développement.
Enfin, PHP s'oriente résolument vers l'orienté objet ( il n'y a qu'à regarder la liste des fonctionnalités déclarées dépréciées dans l'évolution des versions) donc s'intéresser à la POO est forcément un bon investissement à long terme à mon avis (pas seulement PHP d'ailleurs, pour d'autres langages aussi, et savoir utiliser exceptions, prototypes, héritages, etc peut rentrer un peu dans la même démarche côté client avec le javascript).

Merci Gwym, je vais essayer de regarder ça de plus près
... mais ça fait une grosse différence avec mes habitudes.

En tout cas, y'a un truc que je vais appliqué, c'est la modélisation MVC, ça sera beaucoup plus maintenable que mon dernier projet

Arghh ! ! !

Mais tout a changé !

Maintenant les jeunes ne parlent plus que de PHP en POO,
avec des fonction MySQLi pour s'adresser à la BD mysql
avec PDO comme interface d'accès
avec cake PHP comme framework
avec gagatemplate comme moteur de template
avec WAMP à la place de easyPHP

Mais y sont fous ...

Au fait, est-ce que les fonctions mysql_ continuent à fonctionner ?
Ca serait la cata sinon.

Bon, moi qui ai l'habitude de php2, je me demande si je peux toujours développer en avec les anciennes méthodes ?
... ou est-ce qu'elle seront obsolètes et non supportées très prochainement ?

Merci pour votre aide

Mysql n'est pas la seule base de donnée existante (j'utilise postgresql, mais le NoSQL devient aussi à la mode actuellement), et des outils comme easyPHP sont des simplifications pour ceux qui veulent éviter l'installation manuelle de différents programmes.

Les fonctions mysql_ continuent de fonctionner, mais ne permettent pas d'accéder à certaines fonctionnalités de versions mysql plus récentes. Si tu ne fais que du SQL "de base", c'est amplement suffisant, et dans ce cas PDO est utile pour changer de base de donnée plus tard.

Je te conseille de partir de suite avec une version 5.3 et les warnings stricts et E_DEPRECATED et E_USER_DEPRECATED. Cela t'évitera de devoir reprendre ton code avant un bon bout de temps

Il y a par exemple une liste des fonctions qui vont disparaitre ici entre 5.2 et 5.3 :
http://ca2.php.net/manual/fr/migration53.php
Dans le menu à gauche, il y a la même chose pour les incompatibilités entre 4 et 5.0, 5.0 et 5.1, 5.1 et 5.2.

php2 n'est plus vraiment à l'ordre du jour

La question est donc de savoir si tu as un projet complexe ou en équipe... ou encore si tu comptes te faire embaucher en tant que dev PHP.

Perso, je trouve l'Objet très surévalué... ça fait 20 ans que je suis dans l'info, et 20 ans qu'on promet des langages permettant de faire de la réutilisation... le facteur bloquant restant en fait toujours le même : le facteur humain ! Pour moi, le principal intérêt d'un langage (et d'un framework) doit être sa facilité d'usage, sa productivité. Parce qu'on ne réutilise pas, on refait et on remplace toujours.

Cool ! donc je continue comme ça, je n'ai pas l'intention de changer de base.
Y'a juste que je vais peut-être avoir besoin des transactions, je me demande si c'est possible avec ma config actuelle.

voila un super conseil merci Gwyn! Je vais faire ça, comme ça je serai averti des vieilles fonctions que j'utilise.

C'est un projet perso, je serai tout seul dessus et coté professionnel, ça doit faire 10 ans que je n'ai plus développé
Donc le procédural ira très bien

J'suis d'accord avec toi, beaucoup sont séduit par le coté réutilisable et flexible mais ce ne sont que des vœux pieux. A part dans le cadre d'une équipe de projet, c'est plus une idéologie qu'un gain de temps pour moi

Pour l'anecdote, j'ai abandonné mon dernier jeu à cause d'un pote qui s'est mis en tête de mettre à jour le code sous eclipe avec un énorme framework over performant ... au finish j'ai laissé tombé car c'était devenu trop contraignant de faire des modifs dans ce code.

Bref .. les solutions les plus simples sont encore et toujours les meilleures

J'suis en 5.3.2 et voici ce que j'ai dans le php.ini

error_reporting = E_ALL | E_STRICT

J'ai l'impression que ça couvre les E_DEPRECATED et E_USER_DEPRECATED.

Je me trompe ?

Effectivement, "E_ALL : Toutes les erreurs et alertes supportées sauf le niveau E_STRICT".

Ah ce fameux dilemme. Si on cherche attentivement, je suis sur qu'on peut retrouver des posts de moi-même sur ce forum où je défendait le procédural dur comme fer....

.... je code en objet maintenant.


Les critiques adressé à la programmation orienté objet sont généralement des critiques de mauvais code pas suffisamment orienté objet. BIEN programmer en orienté objet est une tâche extrêmement complexe et ardue. J'assiste chaque années à diverses conférences sur les design pattern, et ce n'est pas simple. Il suffit de jeter un oeil au dependency container du framework Symfony pour se rendre compte à quel point ca peut devenir complexe de bien subdiviser toutes les responsabilité du code.

... Si c'est bien fait: on ré-utiliser, les composants en les ré-assemblant. Si c'est mal fait: on doit reforger ou remodifier les composants.

Et oui, c'est plus long, surtout au début. Car on fait des erreurs sans arrêt et on arrête pas de revoir notre modélisations, car ... bah car on ne modélise pas complètement avant de programmer en fait

Mais une fois l'ensemble des concepts bien intégré, on peut abstraire une grande partie des tâches. Par exemple ne plus écrire une seule ligne de requête SQL.... grace à Doctrine, une surcouche à PDO.



Pour moi, il ne fait aucun doute qu'un développement orienté objet apporte des atout majeurs vis-a-vis le procédural en ce qui concerne les projets de tailles importantes.
- Plus facile à documenter (via des outils comme PHPDocumentor)
- Plus facile à tester (via des test unitaires, tel que PHPUnit)
- Plus facile à débugger (à condition d'utiliser un bon debuggueur, tel que XDebug)... les bugs sont rarement généraliser: le code étant ré-utilisé, on corrige à un seul endroit.
- Plus facile à travailler en équipe: chacun peut se charger d'un "module"
- Force à structurer son travail.
- Force à réfléchir à la structuration de son travail.
- Aide à uniformiser les méthodes de programmation.
- Moins de code dans chaque fichier ou fonction (aka. méthodes)
- Code plus clair car on utilise chaque objet sans savoir comment ils doivent fonctionner à l'interne.


... et tout un tas d'autres trucs



Bref, oui tu va perdre du temps, ta productivité va baisser en flèche au début, mais tu va être regagnant à long terme.

Pour ma part, ça fait quelques années que je développe en PHP et je n'ai jamais trouvé utile de passer totalement à la POO, enfin c'est relatif...

Dans le cas des SGBD, la POO devient intéressante, surtout parcequ'elle permet de mettre en place un singleton, des gèrer les erreurs, de faire facilement des requêtes préparées, la fonction rollBack(), ... Après on trouve aussi beaucoup d’intérêt avec un système de template par exemple. Mais tout coder en objet, j'y crois pas trop, ça demande un temps de mise en place beaucoup trop important.

Après ça reste mon avis

Ce message a été modifié par Akira le Lundi 25 Octobre 2010 à 13h57