Discussion :

[nath-0-0]

bonjour,

Je voualis savoir si programmer objet avec php amenait bcp de bénéfices?
ou pas du tout et que c'es simplement une autre maière de coder...

Sinon les avantages serait au niveau des performances? on peut faire plus de chose en programmant objet?

Cela change bcp d'employer une technique ou une autre?
Pour l'instant je programme normal, peut etre devrais-je me mettre a l'objet?

merci pour vos remarques...

[macbook]

Faire de l'objet pour faire de l'objet n'apporte rien.

Il faut "penser" en architecture objet, et non en objet. On peut créer une classe pour afficher un titre. Ce n'est pas une logique objet. C'est de la gaudriole.

On peut faire toute une application en procédurale sans pour autant sacrifier les performances ou la maintenabilité.

Avant de vouloir faire de l'objet, il faut déjà poser sur le papier l'architecture qui va régir son application.

L'objet en PHP n'est pas, à mon sens, une fin en soi.

[Oluha]

perso j'aime pas le php objet. J'ai repris un site en php objet avec du xml et des templates dans tous les sens et une utilisation de la bdd excessive, ben je peux te dire que c'était une vraie usine à gaz ce truc, immaintenable. Donc après ce très mauvais moment j'ai été dégoutée de la chose

[nath-0-0]

cest sur que pour le titre c'est un peu de trop...
mais je pensais pour tout ce qui est par exemple les fonvtions mysql-php, par exemple, ou pour créer un utilisateur objet, ou me caddie...
des trucs du genre...

bon alors il n'a pas d'avantage a faire du objet, meme si c'est bien pensé?

[davcha]

Si c'est bien pensé, je vois pas pourquoi ça n'aiderait pas...

Si ça te permet de centraliser et de réutiliser du code, c'est plutôt une bonne chose.
Par contre c'est vrai que ça demande un peu plus d'effort de conception et de développement.

[Invité]

Salut,
Perso, je pense qu'utiliser de l'objet en php permet de faire moins de code et d'avoir une meilleure réactivité au niveau de modifications futures.
Evidemment comme toujours "trop de #### tue le ####". L'objet selon moi c'est surtout utile quand tu vas manipuler quelque chose souvent et que ce quelque chose à plein de fonctions le concernant. Si ce quelque chose à plein de cousins alors là c'est indispensable ;-). L'avantage c'est que si tu fais bien les choses, tu fais des classes et après les scripts ne font que quelques lignes (par exemple générer des formulaires d'édition sur des tables de bases de données).

[philac]

quel est l'objet de l'objet......... tout est objet, il y a bien plus d'une décade que l'on parle de programmation orienté objet, sans que personne n'ait vraiement défini ce qu'est " l' Objet " en question, un crayon , une gomme sont des objets.
une idée, un sentiment, une impression, sont des objets, il n'est que d'être (objet "c,tif") pour s'en rendre compte.
Donc orientons.....objectivement

[Mr N.]

Philac tu délires, faut dormir la nuit


Sinon je suis d'accord avec macbook : Faire de l'objet pour faire de l'objet n'apporte rien.

L'objet n'a rien à voir avec php. La question : Je voulais savoir si programmer objet avec php amenait bcp de bénéfices? n'a donc pas beaucoup de sens pour moi.
Si tu te poses cette question, c'est qu'à mon avis tu ne sais pas penser, analyser, concevoir "objet". Et si c'est le cas et que tu t'engages dans la voie POO, tu risques de produire une uzine à gaz telle qu'a pu malheureusement rencontrer Oluha.

Mais d'un autre côté c'est peut-être pas plus mal, c'est sur ses propres erreurs qu'on construire son expérience

[Lorenzo77]

bonjour,

Je voualis savoir si programmer objet avec php amenait bcp de bénéfices?
ou pas du tout et que c'es simplement une autre maière de coder...

Sinon les avantages serait au niveau des performances? on peut faire plus de chose en programmant objet?

Cela change bcp d'employer une technique ou une autre?
Pour l'instant je programme normal, peut etre devrais-je me mettre a l'objet?

merci pour vos remarques...

la différence entre une applications programmé en procédural et une autre bien programmé en objet avec un ensemble de classe est ENORME

non seulement la 2eme pourra etre tres facilement modifié, mais surtout des classes bien pensés pourront reservir pour chaqu'un de tes projets !
c'es simple, a partir du moment ou tu as créer une classe bien pensé, ex : une classe MySQL, tu n'auras normalement plus jamais besoin d'y toucher, et tu auras juste a appeller ces methodes dans tes applications

[Mr N.]

non seulement la 2eme pourra etre tres facilement modifié, mais surtout des classes bien pensés pourront reservir pour chaqu'un de tes projets !
c'es simple, a partir du moment ou tu as créer une classe bien pensé, ex : une classe MySQL, tu n'auras normalement plus jamais besoin d'y toucher, et tu auras juste a appeller ces methodes dans tes applications

Petit bémol tout de même au niveau de la réutilisabilité: hormis les classes génériques (comme MySQL pour reprendre ton exemple) et qui sont des briques pour la construction d'un framework, il est utopique de penser qu'une classe peut servir d'un projet à un autre. Dès qu'on touche à la couche "métier", chaque projet possède sa propre définition d'objets le composant.

[poussinphp]

Pour ma part, je me situe entre les deux.

J'analyse l'utilisation puis je developpe en conséquence. Il ne faut pas oublier que l'objet sert surtout pour la redondance de code.

Refaire 100 fois la même chose c'est embettant et lors des modifications faut fouinner dans tout les fichiers etc... Dans ce cas, l'objet est pratique

Sinon si c'est une chose que tu va crée qu'une seule fois, mieux vaut privilégier le procedurale.

Je pense qu'il vaut mieux savoir utiliser les 2 celon le cas plutot que de faire des objets pour rien ou réecrire 100 fois la même chose.

[ePoX]

Il ne faut pas oublier que l'objet sert surtout pour la redondance de code.

Comme le disait Mr.N plus haut, la réutilisation de classe métier c'est plutot rare.
à cet argument... Qui n'est rééllement valable que dans le cas d'un framework.


Par contre quelque soit le projet que tu fais, l'OO te permettra d'écrire du code plus lisible, plus compréhensible, plus proche du fonctionnel, et ceci est un plus indéniable.

bbye

[nath-0-0]

bon je vois que tout de meme, pas tout le monde est d'accord..

Pour l'argument de la reutilisabilité il me semble que la procedure sert aussi a cela?
Merci de commenter cette derniere remarque et de me dire si je suis pas a coté de la plaque

Si une méthode est meilleur qu'une autre, meme si je debute dans une d'elle, je prefer galérer un peu et ensuite pouvoir utiliser cette méthode plus efficace...
A penser que faut pas toucher ce que l'on connait pas, j'aurais pu rester au cobol....

J'ai fait un peu d'objet, mais c'etait dans le cadre de mes étude et cela remonte a qq années...
Donc je suis pas totalement novice mais...aieaieaie cela risque d'etre dur..

Mais effectivement, a premiere vue je vois pas bcp d'elements a devenir objet dans un site Web...
A part le caddie, les element du caddie et l'utilisateur.....

[Mr N.]

Tout dépend du site web... Pour une vitrine/plaquette commerciale en effet, tout juste besoin de php ^^
par contre pour du e-commerce, tu as des objets métier qui interragissent. Par exemple, comme ça, au feeling :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Article (id, nom, description, prix_unitaire)
Commande (id, date, client_id, mode_reglement)
Ligne_Article (commande_id, article_id, quantite)
Client(id, nom, adresse_livraison, adresse_facturation)

(Pas le temps de faire un diagramme, mais un schema de db est ici suffisant)
Après tu vas avoir différents types d'utilisateurs : les clients et les admins.
Tous deux sont utilisateurs du système (mot de passe, login) mais chacun a des carctéristiques propres (adresse_facturation) => héritage, polymorphisme
...
Enfin bref, la manipulation d'objets représentant le monde réel est pour moi plus intuitif que de manipuler des procédures et des fonctions.

Et puis encore heureux que tout le monde ne soit pas d'accord, ça serait triste sinon

[fguigui]

voir aussi à :
http://www.odi.ch/prog/design/php/guide.php

faire une architecture en 5 couches c'est tout de même beaucoup plus clair, et au moins séparer la présentation des traitements peut permettre une maintenance + facile et une évolution encore + simple.

Les pages de présentation php, ne comprennent qu'un appel au controleur en début de page et uniquement des 'echo' dans le corps de la page, présenter cela à des graphistes leur facilite la tâche.

Même pour des sites simples, ça peut aider !