Quand utiliser du PHP Objet ?

[gcvoiron]

Bonjour,

Je compte créer un nouveau site avec espace membre. Le design étant prêt, je vais m'attaquer au codage.
N'ayant jamais fait du PHP Objet, la question que je me pose est quand faut-il utiliser la programmation objet ? Pour quelles "parties" du site (inscription, connexion...) ?

Merci d'avance, Guillaume.

 

[petit-ourson]

Pourquoi pas pour tout ?

 

[gcvoiron]

Ben je ne sais pas justement...
[Edit] Je n''arrive pas à voir les avantages/inconvénients.

 

[passion]

Que ce soit en objet ou non, cela n'a pas une incidence sur le côté visuel du site mais une prog en objet sera beaucoup plus facilement paramètrable et maintenance associée!

La prog objet est excellente pour structurer ton développement en MVC (Modèle - Vue - Contoleur). Tu sépares tes composants:
- Vue: pages HTML, CSS
- Controleur: Tous tes composants métiers (coeur de ton algo)
- Modèle: Tous tes appels à la base de données

Voilà...

Terminé la prog à l'arrache !!

 

[xTrade]

La prog objet est excellente pour structurer ton développement en MVC (Modèle - Vue - Contoleur). Tu sépares tes composants:
- Vue: pages HTML, CSS
- Controleur: Tous tes composants métiers (coeur de ton algo)
- Modèle: Tous tes appels à la base de données

Je comprends rien à ce que tu dis :lol: mais je confirme que lorsqu'on est habitué à la programmation objet, c'est difficile de s'en passer.
Ceci dit, la PoO php est plutôt pourrie par rapport à java/c++

 

[passion]

Je comprends rien à ce que tu dis

http://fr.wikipedia.org/wiki/Mod%C3%A8l ... %C3%B4leur

 

[i911]

La prog objet est excellente pour structurer ton développement en MVC (Modèle - Vue - Contoleur). Tu sépares tes composants:
- Vue: pages HTML, CSS
- Controleur: Tous tes composants métiers (coeur de ton algo)
- Modèle: Tous tes appels à la base de données

Je comprends rien à ce que tu dis :lol: mais je confirme que lorsqu'on est habitué à la programmation objet, c'est difficile de s'en passer.
Ceci dit, la PoO php est plutôt pourrie par rapport à java/c++

En quoi est-ce que la prog objet Php est plus pourrie que les autres ? Je code avec des objets en Php, la structures est très bien je t'assure. Les avantages ? Plusieurs...mais disons que le passages de paramètres au travers d'un seul objets plutôt que d'envoyer des masses de variables lors de requêtes plus complexes, c'est très sympa...ça permet également une structure très droite, et coté réutilisabilité du code c'est génial.

 

[Bool]

A propos, j'ai une approche sensiblement différente du "MVC" à priori, surtout pour le contrôleur à vrai dire :
- Vue : affichage, donc template / CSS
- Controleur : traitement des "entrées" / "sorties" : URL, formulaires, redirections, etc.
- Modèle : traitements métiers, dont les appels à la base de données donc.

J'ai une approche vraiment biaisée ou bien finalement c'est un peu comme on le sent ?

 

[xTrade]

En quoi est-ce que la prog objet Php est plus pourrie que les autres ? Je code avec des objets en Php, la structures est très bien je t'assure.

Des détails, comme être obligé d'utiliser this à tout bout de champs, c'est d'un chiant

 

[tonguide]

A propos, j'ai une approche sensiblement différente du "MVC" à priori, surtout pour le contrôleur à vrai dire :
- Vue : affichage, donc template / CSS
- Controleur : traitement des "entrées" / "sorties" : URL, formulaires, redirections, etc.
- Modèle : traitements métiers, dont les appels à la base de données donc.

J'ai une approche vraiment biaisée ou bien finalement c'est un peu comme on le sent ?

idem.

Je vois pas l'intérêt de mettre le cœur de la programmation dans le contrôleur, ça reviendrait à dire que tu fais tes class/fonctions, et pouf tu les utilises dans le même fichier... Aucun intérêt.

Donc oui, tu fais ton modèle et tu utilises les modèles via le contrôleur selon les actions du visiteur et tu renvois le visuel ensuite

 

[i911]

En quoi est-ce que la prog objet Php est plus pourrie que les autres ? Je code avec des objets en Php, la structures est très bien je t'assure.

Des détails, comme être obligé d'utiliser this à tout bout de champs, c'est d'un chiant

Oh je vois, ok pour l'auteur du message je te conseille quand même de jeter un coup d'oeil à l'OO de Php si tu n'a pas peur de t'essouffler en tapant 4 lettre et disant que l'OO en Php est POURRIE.

Je le vois pas celui-là devoir taper 8 lignes de code SET/GET pour créer une propriété d'objet en vb.net...ohlala...

 

[webmister62]

Lol, le gars il pose une question pour savoir c'est quoi l'objet et vous partez dans un débat MVC et compagnie. A coup sûr il est largué ^^

Avant de développer en MVC, faudrait deja connaitre les fondements de la programmation objet. En résumé, ca te permettra de réutiliser du code quand tu veux sans devoir le ré-écrire à chaque fois. Pour le reste -> http://fr.wikipedia.org/wiki/Orient%C3%A9_objet

 

[xTrade]

En quoi est-ce que la prog objet Php est plus pourrie que les autres ? Je code avec des objets en Php, la structures est très bien je t'assure.

Des détails, comme être obligé d'utiliser this à tout bout de champs, c'est d'un chiant

Oh je vois, ok pour l'auteur du message je te conseille quand même de jeter un coup d'oeil à l'OO de Php si tu n'a pas peur de t'essouffler en tapant 4 lettre et disant que l'OO en Php est POURRIE.

Je le vois pas celui-là devoir taper 8 lignes de code SET/GET pour créer une propriété d'objet en vb.net...ohlala...

Ouai, t'as raison, c'est bien de ne pas reconnaître les défauts d'un langage qu'on utilise (et php en est bourré), de la perte de lisibilité, de l'augmentation du nombre de caractère donc des fautes de frappes qui peuvent en découler (surtout que php est très permissif...)
M'enfin brèfle, le faineant que je suis retourne à ses 50000 lignes de code... :roll:

 

[DadouDuck]

Le PHP à bien des défauts, c'est vrai, mais il apprend vite et les corriges petit à petit, la POO dans PHP n'est que très récent. Il possède donc encore des lacunes de jeunesses, mais l'usage de la POO de PHP reste tout de même très intéressant quand cette dernière est utilisé à bon escient, c'est à dire qu'il ne faut pas faire de la POO partout, mais uniquement quand il y en a besoin

 

[webmister62]

oui, et puis il y a pas mal de frameworks PHP qui aident à un bon développement, comme cakePHP.

 

[Leonick]

le problème, c'est de croire que POO c'est obligatoirement du code structuré et programmation traditionnelle c'est le foutoir.
J'en ai vu du code en poo qui était du grand n'importe quoi.
du vrai MVC je n'en ai jamais vu dans les divers scripts php en poo. Ce n'est pas en rajoutant du pseudo langage qu'on fera vraiment du MVC.

Sinon, pour voir que le php ne produit qu'un sous langage objet, en version 5 il ne possède pas le polymorphisme, qui est un atout indéniable en java et qui fait, vraiment, justifier l'utilisation de la poo

Est-ce qu'une page valide xhtml 1.1 strict est mieux structurée qu'une page valide html 4. Rien ne permet de le dire. on peut très bien faire du xhtml strict avec une mise en forme en tableau, voire en replaçant les <td></td> par du <div></div>

 

[webmister62]

Je suis aussi d'avis qu'il n'y a pas photo entre la poo Java et la poo Php. Mais c'était pas l'objectif du sujet je crois. Le monsieur voulait juste savoir l'intéret d'utiliser l'objet dans son développement, et où.

 

[tonguide]

ça c'est sûr
Ceci étant, même en code linéaire, j'ai jamais vu de truc propre non plus. Remarque, j'évite les programmes externes, donc j'en ai pas vu des masses.

Il y a PHPclasses.org qui a des classes PHP 5 plutôt sympa et dont le code est parfois très propre. (désactivez le JS pour aller sur ce site, c'est mieux, sinon il est lent.)

 

[Leonick]

Je suis aussi d'avis qu'il n'y a pas photo entre la poo Java et la poo Php. Mais c'était pas l'objectif du sujet je crois. Le monsieur voulait juste savoir l'intéret d'utiliser l'objet dans son développement, et où.

l'intérêt, c'est juste où il le faut. Et créer un objet, l'instancier, pour n'avoir qu'une seule fonction dans cet objet, autant rester sur de la programmation "classique"

 

[webmister62]

oui de toute façon, gcvoiron, avant de coder ton site en objet, impregne toi des fondements de la POO. Mais le plus adapté à ton cas sera surement encore de la programmation linéaire.

Parce que l'objet, même si c'est normalement plus naturel, plus souple, etc etc (le paradis du dev quoi ) , ça a souvent plus de mal à rentrer chez le néophyte habitué aux code "classiques"

 

[unpassant]

En quoi est-ce que la prog objet Php est plus pourrie que les autres ? Je code avec des objets en Php, la structures est très bien je t'assure.

Des détails, comme être obligé d'utiliser this à tout bout de champs, c'est d'un chiant

Oh je vois, ok pour l'auteur du message je te conseille quand même de jeter un coup d'oeil à l'OO de Php si tu n'a pas peur de t'essouffler en tapant 4 lettre et disant que l'OO en Php est POURRIE.

Je le vois pas celui-là devoir taper 8 lignes de code SET/GET pour créer une propriété d'objet en vb.net...ohlala...

Elle n'est pas "POURRIE" mais vraiment limité par rapport aux autres langages orientés objets.

 

[Bool]

D'un autre coté le polymorphisme avec un langage peu typé et dont les paramètres des méthodes sont optionnels, je vois même pas comment le mettre en place.... ni ce que ça apporterait d'ailleurs.
A moins que PHP permette un jour le typage des paramètres de fonctions (comme pour les fonctions internes quoi). Mais aux dernières nouvelles ça avait été refusé sur la ML.

Coté gestion de l'objet, ce qui me gène le plus pour le moment c'est la gestion du statique à vrai dire. Pour le reste, avec l'arrivée de "traits" avec PHP 5.3, je pense qu'on est pas si mal lotis.

 

[tonguide]

ce qui me gène le plus pour le moment c'est la gestion du statique à vrai dire.

Tu peux détailler ce qui te gêne ?
La gestion par PHP, l'utilisation, ou autre chose ?

Je m'en sers via un set/get pour avoir accès à PDO sans trop m'embêter, solution de facilité certes, mais si c'est pas la bonne solution, je préfère de suite l'arrêter.

Elle est pas conseillé en masse, mais dans un cas pareil, ça me semble pas trop gênant. C'est un peu comme un define() pour instance

 

[Bool]

C'est surtout le "self::" qui me gène, qui est en fait interprété à la compilation et donc non surchargeable.

Disons que le soucis vient surtout du fait que j'étais parti pour ré-écrire mes rares classes "singleton" en statique, et qu'au final ça le comportement n'est pas celui que je cherchais.


PS : pour PDO j'utilise une autre classe qui s'occupe de créer ou non une autre instance. Ce qui donne un truc du genre :

$db = kore::$db->instance( 'admin' );
$res = $db->query( "xxxx" );

 

[tonguide]

J'aime pas non plus utiliser "self::" pour une classe classique, mais pour une classe "singleton" par contre, ça me semble presque indispensable (mais je peux me tromper ).

 

[Bool]

Le soucis est là :

class A
{
    static function test()
    {
        self::secondTest();
    }
    static function secondTest()
    {
        echo "versionA", PHP_EOL;
    }
}

class B extends A
{
    static function secondTest()
    {
        echo "versionB", PHP_EOL;
    }
}

B::test();

La méthode "test()" va appeler la "versionA" de secondTest() ; ce qui limite très fortement à mon gout l'utilité de la chose Et surtout, il n'y a à ma connaissance aucun moyen simple de contourner ça.

 

[tonguide]

Je confirme que l'intérêt est pas énorme.
Après ... même si c'est un exemple, je vois pas trop à quel occasion tu t'en sers

Essai peut-être avec les fonctions get_class/get_class_vars etc... Mais après, c'est forcement un peu lourd.

Je doute que __call marche en static (enfin à vérifier, ça pourrait être sympatoche si c'était le cas).

Enfin je dis ça, mais je pense que t'as tout essayé

Tu as prévu une date pour nous montrer tout ce beau code (non je déconne, je sais que t'aimes pas les dates lol)

 

[Bool]

Absolument aucune date non

Déjà il faudrait que le code passe le "standard Zend", et vu comme code sniffer rale pour la malheureuse trentaine de classes utilisées, y a du bouleau

Sinon oui, j'ai essayé pas mal de choses pour le statique, et ne l'utilise plus vraiment pour les classes singletons... sauf quand je suis certain de jamais vouloir surcharger la dite classe ; et ça, c'est rare.

 

[Nico92]

Alors perso, je dirais que la programmation objet dans des pages web n'est absolument pas indispensable. D'ailleurs, elle est parfois fortement deconseillée.

L'objet n'est qu'une réponse à certains besoins : réutilisation de code, evolution coherente dans le temps, encapsulation, etc ...
Cela ne veux pas diure qu'un code Objet sera meilleurs qu'un code non objet. Il y a du bien et du moins bien dans les deux styles.

Je pense que dans le cas d'une application web, l'objet est utile au niveau metier (la couche modele, certainement pas le controleur comme j'ai pu le lire plus haut .
Il est par contre peux utile dans le controleur, et carrement à proscrire dans la vue.

L'instanciation d'un objet demande des ressources. Ils sont donc à utiliser avec des pincettes.
POurquoi utiliser des lites d'objets, ou des collections, alors que de simples tableaux peuvent suffirent (et qui sont 50 fois plus rapides à parcourir) ?

Pourquoi utiliser des objets si ce n'est que pour lui coller des methodes et propriétés statiques. Pourquoi creer des tonnes d'objets communiquant si toutes les composantes sont public ?

L'important, à mon gout, est autre part.

Je persiste à croire que la première étape vers un code propre est la séparation des couches. Cette notion est importante, car une fois acquise, tu pourras apprehender MVC, mais aussi SOA, etc ...
Objet ou pas, il est affolant de voir à quel point peu de gens sont rigoureux sur sur ce codage en couche.
Ex : avoir un affichage ecran au même niveau qu'une requete en base de données, et tu comprend que le principe n'est absolument pas maitrisé.

Mais je peux comprendre, beaucoup de personnes ne sont pas d'accord sur la structure même de MVC (qui semble etre un modele répendandu, et relativement accessible) : Cycle en triangle, ou cycle en ligne ? Je dirais cycle en ligne, mais certains s'obstinent à penser que la cycle en triangle est possible. Pour une appli web, je dis non, mais bon ...

Belle preuve de ce que j'avance : (encore que l'auteur explique le pourquoi)
http://julien-pauli.developpez.com/tuto ... ontroleur/

par contre, oà, je ne suis plus du tout d'accord.
http://baptiste-wicht.developpez.com/tu ... ption/mvc/

Bref, je m'egare, mais à mon avis, apprends plutot à bien découper ton code, et fais du code propre, même s'il est procedural.

Je me permes de te conseiller deux bouquins très interressants :

Best practices PHP 5

Analyse et conception orientées objet

 

[gcvoiron]

Merci pour vos réponses et liens.

J'ai déjà fait de la programmation objet, pour un jeu "UNO" en C++. Dans ce jeu, je voyais pourquoi utiliser la programmation objet, pour gérer le jeu, les cartes... Mais en PHP, par exemple, pour une page d'inscription, pourquoi utiliser de l'objet, si ce n'est pour avoir un code plus clair/structuré ? Y a t-il d'autres avantages ?

 

[Leonick]

Mais en PHP, par exemple, pour une page d'inscription, pourquoi utiliser de l'objet, si ce n'est pour avoir un code plus clair/structuré ? Y a t-il d'autres avantages ?

pour être "in the move". Tout comme certains affichent le logo "xhtml valid", même quand ce n'est pas vrai.
le code n'est pas vraiment plus clair, loin de là.

 

[tonguide]

Je prend mon exemple pour illustrer ...

J'ai une classe pour générer le formulaire selon certains critères. (en libre, tu dois avoir Zend_Form comme librairie qui fait ça)

ça permet au moins d'être uniforme la dessus.

En second, si il y a une liste (<SELECT>), je la centralise également dans une classe, et en troisième, si il y a une vérification (regex ou n'importe quoi, pour la validité des champs que rentre tes visiteurs), c'est également centralisé.

Exemple, je dois vérifier le prénom, j'ai limité à 10 caractères (c'est un exemple). J'ai un admin qui permet de modifier un compte, j'ai une zone membre pour éditer son compte, j'ai un admin pour ajouter un compte, et une zone membre pour ajouter un compte. Et puis, j'ai également une liste de contact où on peut entrer le prénom de son contact.

Seulement, j'ai systématiquement limité à 10 le prénom ... et je m'aperçois qu'il y a un prénom qui fait 25 caractères que je n'avais pas pensé ... J'ai pas de centralisé via une class, je me tape chaque fichier à modifer (ici, au moins 5, dans d'autres cas, ça peut être 100 ...), j'ai centralisé via une class, j'ai un seul fichier, une seul ligne à modifier.

Niveau maintenance, c'est énorme, niveau rapidité de dev, c'est énorme (et ça évite les erreurs de copier/coller), niveau travail en groupe, idem et j'en passe.

Donc j'aurai tendance à dire que l'objet est indispensable en dehors d'un tout petit projet qui n'a pas pour ambition d'évoluer.

 

[gcvoiron]

Ok pour l'exemple. Mais si tout est déjà centralisé dans un fichier de fonctions... ça revient au même, non ?

 

[Leonick]

Ok pour l'exemple. Mais si tout est déjà centralisé dans un fichier de fonctions... ça revient au même, non ?

tout à fait.
Car trop de personnes comparent un développement anarchique avec la poo. Alors qu'en développement plus traditionnel, rien n'empêche de faire du code (sous forme de fonctions) qui soit réutilisable.
Tout comme on peut avoir du html 4 mieux structuré que du xhtml strict

 

[tonguide]

Les possibilités des fonctions sont très limités quand elles sont isolés (sans classe, c'est forcement isolé, sauf si on commence à mettre 45 global par fonction et/ou 145 paramètres), une classe c'est un ensemble de fonction (méthode) qui, pour faire simple, peuvent se renvoyer des données et qui ont des possibilités que n'a pas une simple fonction (et vraiment pas des moindres).

Mais là, c'est vraiment rentrer dans les détails, il y a suffisamment de tutoriel sur le thème pour t'expliquer. Chose que je ne veux pas faire, pour des raisons évidentes de timing

Leonick, tu sais réellement te servir de la POO ? parce que tes commentaires montrent vraiment l'opposé. Même si un code utilisant POO n'ai pas forcement mieux codé que du procédural, entre celui qui maitrise un minimum la POO, et celui qui maitrise que le procédural, il y a une différence véritablement énorme.

Evidemment, si tu te bases sur le fait que tout ceux qui prog en objet sont mauvais, on va pas allé loin. Mais ce n'est pas parce que tu n'as pas saisis l'intérêt que forcement, c'est une méthode à oublier, et surtout l'a déconseillé à ceux qui veulent s'en servir.

 

[Leonick]

si tu te bases sur le fait que tout ceux qui prog en objet sont mauvais,

non, mais le contraire non plus. Donc comparer un développement poo bien développé avec un mauvais développement procédural, c'est sur qu'on donne l'avantage à la poo.
Et puis bon, la poo en php ce n'est pas vraiment de la poo. Il manque énormément d'avantages (voir plus haut).
le php reste un langage non typé, donc déjà, ça limite beaucoup

 

[tonguide]

L'argument fatal, c'est le non-typé.

Et je n'ai pas dis que je compare un bon dev POO et un mauvais dev Procédural, mais au contraire, 2 bon dev POO/Procédural ... Et bah il est indéniable qu'un bon dev POO aura un code plus portable, plus maintenable, facilitant le travail d'équipe, facilitant la réutilisation de code (et je ne parle pas de structure ni de propreté) et faisant gagner du temps. (car tu ne peux pas automatiser autant avec des simples fonctions, comparé à une série de class/librairie etc.)

J'espère que sur ça, on est au moins d'accord ?

 

[Leonick]

J'espère que sur ça, on est au moins d'accord ?

oui.
Mais en fait, c'est vrai que si on se met à la poo avec php, on trouve ça super.
Mais quand on a commencé avec java, tout de suite ça parait moins intéressant. Car pour une bonne réutilisabilité du code, c'est vrai que le polymorphisme est très intéressant. Et avec un langage non typé, adieu.
la capture des exceptions aussi, mais elle existe aussi en php4, à un degré moindre, soit.

 

[tonguide]

la question étant PHP objet, j'y ai répondu
Et comme effectivement, je ne connais que PHP (ou croit connaitre ) et malheureusement pas Java, je juge sur ce que je peux juger.
C'est à dire, procédural / poo (qui était justement la question).

 

[Nico92]

la question étant PHP objet, j'y ai répondu
Et comme effectivement, je ne connais que PHP (ou croit connaitre ) et malheureusement pas Java, je juge sur ce que je peux juger.
C'est à dire, procédural / poo (qui était justement la question).

Justement, même si je suis d'accord avec toi sur les aspects positifs de l'OO, fais un peu de java ou de C#, et tu verras toute la dimension et la subtilité de l'OO. Comme tu dis, on croit connaitre, mais je t'assure qu'on en apprend presque tout les jours ^^

Pour vraiment tirer profit de l'OO, il faut modéliser.
Faire de l'objet pour de l'objet de sert strictement à rien. Au pire, c'est une façon de présenter son code, rien de plus.
J'ai rarement vu du code objet en php tirant partie de l'héritage (il faut dire que je n'ia pas bcp cherché ^^).

Par contre, c'est vrai que le non typage de PHP est un frain au dev en OO.
L'abscence de paquetage aussi (je préfère cette notion à celle d'espace de nom que j'ai décidément du mal à piger sans m'arracher les cheveux).
Mais ca, c'est comme pour tout, il faut y avoir gouté pour s'en rendre compte