[Résolu] Comment coder proprement ?

[Cartoristal]

De toute façon quelqu'un commencera forcément sans utiliser la POO ni les fonctions et tout le tintouin...

C'est après, lorsqu'il aura besoin de passer à une future V2 ou je ne sais quoi d'autre qu'il se rendra compte que son code est illisible par un autre et pas modifiable ...

En tout cas, je pense que je m'y mettrais quand sa m'apportera des fonctionnalités que je ne trouve pas dans mes bases de php ...

L'AJAX, par contre, peut réellement se montrer intéressant dès le départ...

[joshua]

Je en suis aps d'accord avec toi CARTORISTAL. Beaucoup maintenant commence en objet... Et c'est tant mieux!

Pourquoi? parce que l'objet, c'est natif et compréhensible. Je veux dire que l'objet, c'est a l'image de la nature. on définit un tout et ses propriétés et ses attributs. Rien de plus simple. Alors qu'en procédural, on essaie de plier du code a nos envies en se torturant les meninges.
Honnetement quand on a pigé le truc, y'a plas plus rapide et plus facile a entretenir que de l'objet.

[Sephi-Chan]

Je pense que si le procédural semble à certain la bonne voix pour commencer, c'est parce que le SDZ l'enseigne.

[uriak]

Oui et non. Moi je commence direct en objet parce que je code en C++ depuis un bail. Mais même avec ça j'ai eu un peu de mal à saisir le pourquoi de la POO en php, quand tous les objets sont détruits à la fin de la page, quand les variables sont non typées, etc. C'est relativement déroutant quand on a connu le confort d'un langage compilé.

Bon maintenant en pratique, je pensais m'en servir grâce à l'utilisation des sessions, encore raté ^^ Mais c'est de toute façon d'un confort très appréciable en matière de maintenance, même si je trouve qu'être obligé d'utiliser $this-> à l'intérieur même d'un objet est gonflant question rédaction. :/

[keke]

<edit kéké> j'avais pas vu que plein de gens avaient réagit ^^ j'aurais du faire un refresh de ma page avant de répondre, mais bon, tant pis.</edit>

lol
c'est par exeprience que vosu arriverez a vosu convaincre vous meme
personellement ce que ca m'apport de coder en classe :
- propreté
- facil de compreension
- code php moins brouillon car moins de lignes
- facile de modification -> plus besoin daller modifier 5 lignes .. on va dans la methode et on arange ^^

enfin j'ai fai un tour rapide hein ^^

Je programme en OO avec du C++ par exemple, mais j'avoue que le pseudo OO en php ne m'a jamais séduit.
Les exemples que tu donnes ne sont pas vérifiable en C++ et je pense que ce serait pareille en PHP.
-> facilité de Modification ... tu auras toujours 5 lignes à modifier en OO ou pas.
-> Moins de ligne ... c'est pas gagné
-> facilité de compréhension peut-être mais bon casse-tête en cas de reprise de code.
-> Propreté : seul point que je t'accorde.

En outre, je pourrais rajouter professionnalisme, réutilisation de classe, modularité d'ensemble.
Par contre, on peut rajouter : lourdeur dans le développement, rigueur exigée, ralentissement d'exécution (voir rigueur pour compenser), test unitaire plus lourd, connaissance de l'OO propre au PHP nécessaire.

Donc, il me semble que l'OO n'est pas adapté à tout le monde et à tous les projets. Les réponses en "ben oui, ben non" ne me plaisant pas, je dirais que pour un développement simple et rapide, l'OO n'est d'aucune utilité. Pour un développement long et de bonne qualité, l'OO est nécessaire. Pour les projet entre les 2, c'est au choix du développeur.

Magdales utilise de l'OO dans des cas précis, mais cela n'impacte que 1 à 2 % du code...

Kéké.

[pascal]

keke, je vais défendre la POO en PHP

facilité de modification :
_ on modifie une méthode ( objet ) ou une fonction ( procédural avec fonctions ) et ça revient au même;
_ si les arguments de la fonction changent, on doit tracer son utilisation dans tous les scripts et modifier cela. avec une approche objet, les arguments peuvent changer sans que l'appel à la méthode soit changé

=> on a surtout un avantage basique de l'OO : l'encapsulation des données.

moins de lignes :
_ c'est plus long ( verbeux ? ) d'écrire une classe que des fonctions, mais on obtient moins de lignes dans le script utilisateur qu'avec un code classique sans fonctions / classes. c'est dans ce sens là qu'il faut comprendre "moins de lignes"

facilité de compréhension :
_ c'est jamais simple de reprendre un code
_ ça dépend de la documentation inline et hors du code : les tests unitaires permettent de documenter par des exemples d'utilisation des méthodes

lourdeur et rigueur :
_ oui, c'est une syntaxe à apprendre, mais à l'utilisation on y gagne sur tous les plans

ralentissement d'exécution :
_ faux débat : qu'est-ce qui coute le plus cher : un dev de qualité, débugguer du paté ou un serveur un peu plus puissant ?
le coût se situe du coté du développement, et les performances de l'objet en PHP sont bonnes comparé aux fonctions et au paté, et même très bonnes si on considère les bonnes pratiques OO vs le code paté à débugguer.

pour les tests unitaires en PHP, SimpleTest propose un environnement fort sympathique et complet, facile à prendre en main.

ce sujet de discussion est une approche de l'objet en PHP, on ne parle pas encore de conception objet, de design patterns, de composition, d'interfaces ... mais on pourra y venir sur d'autres sujets.

A+

Pascal

[X-ZoD]

ce n'est pas verifiable en c++ parce que par defaut c++ c'est de l'objet
moi quand je cite ces criteres c'est parce que je compare le codage avec et sans objet ... et la clairement mes arguments prennent leurs sens
en gros mes arguments concerne la poo dans le context ou tu compare le procedural et l'objet dans un meme langage

un code procedurale peut etre claire et propre aussi
forcement on ne fera pas de l'objet pour un mini proj rapide ...
mais pour un projet a long terme et qui peut etre repris ... ca fait gagner un temps considerable
apres tout depend de coment tu fais de l'objet -> correct ou degueulasse ^^

pour en revenir au c++
tu pense réelement que coder un projet en procedural est mieux qu'en objet ? -_-
c'est comme si tu me disais que c'est mieux de coder en c plutot qu'en c++ car effecitvement la version procedural du c++ c'est du c

[Prizor]

Juste un petit coup de gueule pas méchant : en programmation comme ailleurs, quand vous devez vous informer sur un sujet, vous documenter, vous le faites pour de vrai, c'est pas la peine de poser des questions si c'est pour lire quelques lignes de la réponse.
En php (et partout ailleurs), si vous voulez des renseignements sur un détail, n'ayez pas peur d'aller passer de nombreuses minutes à lire des tutos et autres documents, plutôt que de ne faire le travail qu'à moitié.

[Raoull]

pascaltje, il ya un truc, même 2, que je cerne pas dans ce que tu as dit :

(...)
mais aussi modifier le script utilisant les fonctions : on doit ajouter partout $race aux arguments.

c'est facile si tout se trouve dans un seul script, mais si ça se trouve sur plein de pages ?
comment être sûr de ne pas en oublier ? (cf ex de zamentur fonction placer() qui se retrouve partout )
comment être sûr qu'on ne va pas se planter dans un script et taper $rcae au lieu de $race ?

avec une classe, on cache les parametres de fonction dans l'objet.

concretement, on ajoute un membre ( ou attribut ) $race dans la définition de la classe;
ensuite on modifie les méthodes ( équivalent de fonctions ), c'est à dire le code à l'intérieur des méthodes, pour tenir compte de la race. mais on ne modifie pas la signature de la méthode ( le nombre des arguments, en gros ) puisqu'il n'y a pas d'arguments à passer à la méthode : tout est dans l'objet.

ex :
fonction verifierDonnees( $login, $mail, $pass, $pass_confirmation, $race)
devient
méthode verifierDonnees()
avec un objet de structure :

Code PHP :

<?php 

class inscription{

public $login;

public $mail;

public $pass;

public $pass_confirmation;

public $race;

} 

[Harparine]

Je me permets de répondre aussi

1) Non, tu ne modifies que ta classe, en rajoutant l'argument et la propriété dans le code unique de ta classe.

2) Oui, tu déclares tout ça en créant ton objet, donc une seule fois par script : après tu peux faire autant d'appels de méthodes que tu le souhaites. Tu peux même stocker toutes ces infos une seule fois dans toute ton application Web, au moment de la connexion du joueur par exemple, et transmettre l'objet de page en page grâce aux fonctions serialize, unserialize et les variables de session. Le code en devient redoutable de clarté !
En php, ça te donne un truc comme ça :

Code PHP :

<?php 

//Page connexion.php

$joueur = new Joueur($login, $mail, $pass, $pass_confirmation, $race);

$joueur->verifierDonnees();

//On imagine qu'on est à la fin du script : on sauvegarde l'objet dans la session

$_SESSION['joueur'] = serialize($joueur);







//Une autre page, par exemple messagerie.php

$joueur = unserialize($_SESSION['joueur']);

$joueur->verifierDonnees();