[POO] Avantages de la programmation orientée objet en PHP 5 [Débat] - Page 3

TIman · 10/10/2007, 16h52

Citation:

Envoyé par jpsoft

Bon je vais me faire lyncher mais c'est pas grave.
Je suis absolument contre la systématisation de la POO.
Le plus dur est de savoir à partir de quel moment il faut en faire et réciproquement quand il faut arrêter le délire.
Cdt

Total agree

à par pour des librairies et dans certains cas particulier je n'utilise pas de class, mieux vaut préféré à mon avis un bonne méthode de développement, ce qui est clair c'est qu'avec un code pourrit je préfère que celui-ci soit écrit procéduralement qu'avec des class.

Des class OK mais surtout pas tombé dans l'abus (j'ai même eu l'occasion de voir une fois un traitement pour uploader une image qui passait pas 6 classes dont chacunes faisait un petit morceau, autant dire un truc imbuvable)

PS : ne metter pas dans une class, du code dont vous êtes sur que vous allez vous en servir qu'une seule fois !

pot2yaourt · 10/10/2007, 21h22

Salut à tous,

Ce post m'a paru très intéressant, du coup, je me suis livré à qqs expériences et comparaisons entre PHP et C#. J'ai trouvé un comportement différent entre les deux langages au niveau de l'appel des classes.

Si quelqu'un peut m'expliquer le pourquoi de cette différence de comportement et surtout quel langage est "juste" ?

Ci-dessous le code PHP :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
<?php
 
//classe normale
class job_A
{
    public function doIt()
    {
        return "Just do it !<br>";
    }
}
 
//classe abstraite
abstract class job_B
{
    public static function doThat()
    {
        return "Just do that !<br>";
    }
}
 
 
//appel d'une classe normale
$job = new job_A();
echo $job->doIt();
 
//appel de façon abstraite d'une classe normale (bug ??)
echo job_A::doIt();
 
//appel d'une classe abstraite
echo job_B::doThat();
 
?>

Ce que je trouve "bizarre" c'est que l'on puisse appeler une classe dite "normale", comme si on appellait une classe abstraite.

Ci-dessous le même code en C# où la ligne echo job_A::doIt(); en PHP n'a aucune équivalence (où en tous cas je ne l'ai pas trouvé !).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
//classe normale
public class job_A
{
    public string doIt()
    {
        return "Just do it !";
    }
}
 
//classe abstraite
abstract class job_B
{
    //mot-clé "static" obligatoire !
    public static string doThat()
    {
        return "Just do that !";
    }
}
 
//appel de la classe normale
job_A job = new job_A();
this.textBox1.Text = job.doIt();
 
//appel de la classe abstraite
this.textBox2.Text = job_B.doThat();

Merci d'avance pour vos réponses,
Lionel.

Yogui · 10/10/2007, 21h28

Je te l'accorde, appeler une méthode d'objet comme on appellerait une méthode de classe n'a pas grand intérêt. Sur ce coup, PHP n'est pas encore tout à fait au point.

PHP5 a marqué un très grand pas vers un modèle objet idéal, mais nous n'y sommes pas encore

Rappelons que PHP est avant tout un langage de script plutôt qu'un langage compilé, et qu'il a tout intérêt à conserver cette optique.

jpsoft · 11/10/2007, 10h28

Citation:

Envoyé par pot2yaourt

Ce que je trouve "bizarre" c'est que l'on puisse appeler une classe dite "normale", comme si on appellait une classe abstraite.
Lionel.

Bonjour,
Tu ne mélangerai pas un peu les notions d' abstract et de static ?

Quand tu codes job_A::doIt(); tu fais non pas un appel de type abstract, mais un appel à une méthode static d'une classe.

Php est très permissif et pour être sur de coder "propre" rajoute

Code :

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

error_reporting (E_STRICT);

et regarde les alertes générées.
L'appel d'une méthode non static en static '::' génère une alerte.
L'instanciation d'une classe abstraite génère ... rien, une page vide et rien dans la log.
(si quelqu'un à des infos la dessus)

Pour abstract regarde -> http://www.php.net/manual/fr/language.oop5.abstract.php

Cdt

ludosoft · 11/10/2007, 10h39

Bonjour,
Pour continuer sur la maturité de la POO en PHP, je voulais ajouter une petite réfection perso sur la robustesse du code.
Voici une classe :

Code :

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

1
2
3
4
5
6
7
8
9
class Test{
 
	private $aString="Walou !";
 
	public function justPrintIt(){
		print($aString);
	}
 
}

Vous voyez la boulette ? Le « print($aString); » n'affiche rien vu que, pris dans l'élan du codage, j'ai oublié un « $this-> ». Il aurait donc fallu écrire « print($this->aString); » mais bien entendu PHP ne peut pas le deviner.

Tout ça pour dire que ce genre d'erreur, trop facile à faire, est assez dangereuse pour la robustesse d'un code objet PHP. Alors bien entendu si on teste correctement ou si on fait attention, cela n'est pas très problématique mais vu que PHP est plus un langage à objets que objet tout court, j'ai peur que le mélange de la logique d'esprit procédurale et objet engendrent des erreurs d'inattention tels que l'oubli d'un « $this-> » de temps à autre.

C'est peut être moi le tordu mais il m'est arrivé de passer du temps à débusquer ce genre d'ânerie qui ne saute pas aux yeux tout de suite. Peut-être qu'un outil d'analyse de code m'aurait averti que la variable n'était pas initialisée au moment du print mais c'est dommage d'être obligé d'en arriver à utiliser des batteries d'outils pour détecter cette si petite boulette.

Conclusion : quand je code, je ne mélange pas trop le codage des classes et du code « appelant procédural » le même jour...

EDIT : après réflexion il me semble qu'on peut activer un warning pour l'utilisation de variables non instanciées. Alors j'ai rien dit... M'enfin je maintient que le coup du « $this » qui manque c'est très vicieux hein...

zulot · 11/10/2007, 11h27

oula on peut pas être a la place du codeur non plus.

Ton exemple c'est un peu comme le mec qui fait une boucle infini car il a pas fait attention a sa clause d'arret.

Et ca ca n'a rien a voir avec le langage.

Le langage a ses expressions et sa syntaxe a respecter apres c'est au codeur de faire attention.

code34 · 11/10/2007, 13h00

Citation:

Envoyé par pot2yaourt

Salut à tous,

Ce post m'a paru très intéressant, du coup, je me suis livré à qqs expériences et comparaisons entre PHP et C#. J'ai trouvé un comportement différent entre les deux langages au niveau de l'appel des classes.

Si quelqu'un peut m'expliquer le pourquoi de cette différence de comportement et surtout quel langage est "juste" ?

Ci-dessous le code PHP :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
<?php
 
//classe normale
class job_A
{
    public function doIt()
    {
        return "Just do it !<br>";
    }
}
 
//classe abstraite
abstract class job_B
{
    public static function doThat()
    {
        return "Just do that !<br>";
    }
}
 
 
//appel d'une classe normale
$job = new job_A();
echo $job->doIt();
 
//appel de façon abstraite d'une classe normale (bug ??)
echo job_A::doIt();
 
//appel d'une classe abstraite
echo job_B::doThat();
 
?>

Ce que je trouve "bizarre" c'est que l'on puisse appeler une classe dite "normale", comme si on appellait une classe abstraite.

Ci-dessous le même code en C# où la ligne echo job_A::doIt(); en PHP n'a aucune équivalence (où en tous cas je ne l'ai pas trouvé !).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
//classe normale
public class job_A
{
    public string doIt()
    {
        return "Just do it !";
    }
}
 
//classe abstraite
abstract class job_B
{
    //mot-clé "static" obligatoire !
    public static string doThat()
    {
        return "Just do that !";
    }
}
 
//appel de la classe normale
job_A job = new job_A();
this.textBox1.Text = job.doIt();
 
//appel de la classe abstraite
this.textBox2.Text = job_B.doThat();

Merci d'avance pour vos réponses,
Lionel.

classe abstraite et méthode static sont deux notions complètement différentes.

Effectivement si l'exemple que tu donnes fonctionne , il s'agit d'un bug. Car il ne doit pas être possible d'accédèr à une méthode non static d'une classe qui n'est pas instanciée.

L'exemple que tu donnes n'est pas lié aux classes abstraites mais à la méthode static. Quand tu utilises "::" il s'agit d'un accesseur qui permet de faire appel à des méthodes. Pour faire appel à une méthode statique, l'unique moyen est d'utiliser "::"

http://fr.php.net/manual/en/language...ekudotayim.php

Si ta méthode n'était pas statique, tu pourrais l'appeller de la même façon à partir d'un objet qui étendrait ta classe abstraite.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
abstract class job_B
{
    //mot-clé "static" obligatoire !
    public function doThat()
    {
        return "Just do that !";
    }
}
 
class job_C extend job_B
{
 
}
 
$job = new job_C();
echo $job->doThat();

Je rappelle que c'est mal d'utiliser des méthodes et des variables STATIC.

Cela ne doit servir que dans le cadre de design pattern. Et comme ça t'as choqué, c'est très moche (mais autorisé) d'utiliser des "::" pour accéder à des méthodes non statics.

pot2yaourt · 11/10/2007, 14h13

Citation:

Envoyé par jpsoft

Bonjour,
Tu ne mélangerai pas un peu les notions d' abstract et de static ?

En fait, j'étais parti sur l'exemple donné au tout début de la discussion sans trop faire attention aux notions d'abstract...

Toutefois, il faut effectivement bien penser à mettre error_reporting(2048); dans son code car sans ça voici ce qu'il est possible d'écrire sans que PHP ne bronche :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Test
{
    public function sayHello()
    {
        return "salut !";
    }
}
 
$t = new Test();
echo $t->sayHello();
 
//ou pire :
 
echo Test::sayHello();

D'ailleurs, PHP ne bloque pas l'exécution du script lorsqu'il arrive à la ligne echo Test::sayHello();
Il affiche un message d'erreur certes, mais poursuit l'exécution du script !

Lionel.

jpsoft · 11/10/2007, 14h15

Citation:

Envoyé par code34

Je rappelle que c'est mal d'utiliser des méthodes et des variables STATIC.

Cela ne doit servir que dans le cadre de design pattern.

C'est mal ? Pourquoi ça? Et pourquoi pas dans des design patterns ?

La majorité des classes d'une appli web sont mono-instance et pourraient (ou plutôt doivent) être traitées comme des singletons.
Les appels 'static' sont résolus à la compilation. Alors pourquoi ralentir et complexifier en traitant comme du multi-instances des objets que l'on sait pertinemment qu'ils ne seront jamais instanciés plus d'une fois.
Encore une fois, c'est vraiment philosophique comme débat.
Il faut, comme tu le dis si bien, faire la juste mesure, concilier modèle et performance.
Cdt

code34 · 11/10/2007, 14h33

Citation:

Envoyé par jpsoft

C'est mal ? Pourquoi ça? Et pourquoi pas dans des design patterns ?

La majorité des classes d'une appli web sont mono-instance et pourraient (ou plutôt doivent) être traitées comme des singletons.
Les appels 'static' sont résolus à la compilation. Alors pourquoi ralentir et complexifier en traitant comme du multi-instances des objets que l'on sait pertinemment qu'ils ne seront jamais instanciés plus d'une fois.
Encore une fois, c'est vraiment philosophique comme débat.
Il faut, comme tu le dis si bien, faire la juste mesure, concilier modèle et performance.
Cdt

Pour les design pattern tu m'as mal lu

! Utiliser les STATIC dans le cadre de design pattern, cela montre que tu sais ce que tu fais. D'ailleurs tu l'expliques très bien avec l'exemple du singleton.

Utilisez des STATIC en tant que variables globales à toutes les sauces, n'importe ou, n'importe quand, juste parce qu'on maitrise mal les concepts de visibilité, c'est du n'importe quoi.

Je conseille fortement aux débutants en Orienté objet d'utiliser pour commencer des variables privates, puis quand vous maitrisez bien des protected pour comprendre l'héritage, et en dernier lieu les static pour aborder les design pattern.

Mais surtout n'utilisez pas les static au départ !!!

jpsoft · 11/10/2007, 14h36

Citation:

Envoyé par pot2yaourt

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Test
{
    public function sayHello()
    {
        return "salut !";
    }
}
 
$t = new Test();
echo $t->sayHello();
 
//ou pire :
 
echo Test::sayHello();

D'ailleurs, PHP ne bloque pas l'exécution du script lorsqu'il arrive à la ligne echo Test::sayHello();
Il affiche un message d'erreur certes, mais poursuit l'exécution du script !

Lionel.

Toute la question est de savoir s'il faut rajouter 'static ' à la méthode sayHello et utiliser l'appel static Test::sayHello(); ou interdire cet appel.
Dans ce cas précis, je penche pour l'appel static beaucoup plus performant et moins consommateur de mémoire, la création d'une instance n'apportant absolument rien.
Attention tout de même, chaque cas est différent et il ne faut pas non plus faire l'erreur inverse en rendant static une méthode ou variable qui ne le sont pas.
Cdt

jpsoft · 11/10/2007, 14h47

Citation:

Envoyé par code34

Pour les design pattern tu m'as mal lu

! Utiliser les STATIC dans le cadre de design pattern, cela montre que tu sais ce que tu fais. D'ailleurs tu l'expliques très bien avec l'exemple du singleton.

Utilisez des STATIC en tant que variables globales à toutes les sauces, n'importe ou, n'importe quand, juste parce qu'on maitrise mal les concepts de visibilité, c'est du n'importe quoi.

Je conseille fortement aux débutants en Orienté objet d'utiliser pour commencer des variables privates, puis quand vous maitrisez bien des protected pour comprendre l'héritage, et en dernier lieu les static pour aborder les design pattern.

Mais surtout n'utilisez pas les static au départ !!!

Là, je comprend mieux ton discours. Dans un cadre d'apprentissage de conception objet, c'est logique. J'ai juste réagit par rapport au sujet du thread. Dans le cadre de dev objet en php, le singleton (design-pattern) induit le static. Et comme beaucoup de singletons .....

Cdt

ludosoft · 11/10/2007, 15h05

Citation:

Envoyé par zulot

oula on peut pas être a la place du codeur non plus.

Ton exemple c'est un peu comme le mec qui fait une boucle infini car il a pas fait attention a sa clause d'arret.

Et ca ca n'a rien a voir avec le langage.

Le langage a ses expressions et sa syntaxe a respecter apres c'est au codeur de faire attention.

Yep, tout à fait d'accord pour le fait que le développeur est responsable de ce qu'il fait. Y'a juste qu'une boucle infinie c'est une erreur au niveau algorithmique et que le coup du "this" c'est, à mon avis, une peau de banane syntaxique. Et dans ce cas c'est bien lié au langage. Après il est vrai qu'on est pas obligé de marcher dessus

! Suis-je donc le seul à avoir glissé dessus ?

GrandFather · 11/10/2007, 15h34

Franchement, aborder le développement de grosses applications PHP en faisant l'impasse sur la POO ne me paraît pas raisonnable... A moins d'abandonner toute possibilité de maintenance évolutive. D'autant que si vous adoptez un framework MVC, ce qui est fortement recommandé, l'usage de la POO vous est quasiment imposé.

code34 · 11/10/2007, 16h32

Citation:

Envoyé par GrandFather

Franchement, aborder le développement de grosses applications PHP en faisant l'impasse sur la POO ne me paraît pas raisonnable... A moins d'abandonner toute possibilité de maintenance évolutive. D'autant que si vous adoptez un framework MVC, ce qui est fortement recommandé, l'usage de la POO vous est quasiment imposé.

et oui car le rôle de la programmation OO s'est d'économiser le nombre de lignes, et les caractères en informatique dieu sait que ça coute cher en encre !

berceker united · 11/10/2007, 18h30

Citation:

Envoyé par GrandFather

Franchement, aborder le développement de grosses applications PHP en faisant l'impasse sur la POO ne me paraît pas raisonnable... A moins d'abandonner toute possibilité de maintenance évolutive. D'autant que si vous adoptez un framework MVC, ce qui est fortement recommandé, l'usage de la POO vous est quasiment imposé.

Ha ouais ? c'est dans quel saison de "NNawak" parce que je connais pas cette épisode

.
Fortement recommandé un MCV?

TIman · 11/10/2007, 18h49

Citation:

Envoyé par code34

et oui car le rôle de la programmation OO s'est d'économiser le nombre de lignes, et les caractères en informatique dieu sait que ça coute cher en encre !

Un code en POO prendra toujours plus de place que du procédural, je te me met au deffit de me trouver un contre example !

il n'y a aucune mauvaise technique, il y a que des mauvais choix et ça, ça dépent du dévelppeur

code34 · 12/10/2007, 09h30

Citation:

Envoyé par TIman

Un code en POO prendra toujours plus de place que du procédural, je te me met au deffit de me trouver un contre example !

il n'y a aucune mauvaise technique, il y a que des mauvais choix et ça, ça dépent du dévelppeur

C'est une évidence.

En objet tu ne travailles pas avec des variables mais avec des objets. Tu travailles sur des références, et le gros paté de code que t'as en impératif qui fait tout, est éclaté en petit composant beaucoup plus simple à comprendre, et optimiser.

Autant, j'imagine que tu te réjouir d'utiliser les fonctions en impératif parce que ça rend plus clair ton code, autant en objet le concept est beaucoup plus abouti.

Dans les codes impératifs, tu retrouves régulièrement des bouts de code un peu partout qui font la même chose. C'est une question d'abstraction.

Exemple : passer des paramètres au fonctions.

mafonction(mavariable1,mavariable2,mavariable3,mavariable4,mavariable5);

devient en objet

mafonction(monobjet);

jpsoft · 12/10/2007, 10h45

Citation:

Envoyé par GrandFather

Franchement, aborder le développement de grosses applications PHP en faisant l'impasse sur la POO ne me paraît pas raisonnable... A moins d'abandonner toute possibilité de maintenance évolutive. D'autant que si vous adoptez un framework MVC, ce qui est fortement recommandé, l'usage de la POO vous est quasiment imposé.

Bonjour

Tu as donné L'Argument majeur. Grosse application + développement collaboratif => MVC et donc POO.

Il faut se poser la question d'utilisation de MVC et de POO dans le cas de petites/moyennes applications avec 1 ou 2 développeurs.

Il ne faut pas perdre de vue que développer en MVC et donc généralement avec un framework, demande que le modèle soit parfaitement documenté. Cela demande non plus de savoir coder en Php, mais de maitriser le framework et le modele mvc sur lequel on s'appuie et plus généralement la POO.
J'ai récemment eu à intervenir en task force sur une application conçue sur un framework MVC et ORM d'une société disparue, s'appuyant lui même sur du smarty et du PEAR, sans aucune doc, et là, je ne souhaite cela à personne.

Bilan: Constat de non récupération, évolutions réduites au minimum, et réécriture totale conseillée.

Il est tout aussi impensable d'obliger à faire de la POO que de l'interdire.
Il faut juste être conscient des avantages et des inconvénients qui ont été évoqués tout au long de ce forum.

Bonne journée à tous
Cdt

code34 · 12/10/2007, 12h39

Citation:

Envoyé par jpsoft

Bonjour

Tu as donné L'Argument majeur. Grosse application + développement collaboratif => MVC et donc POO.

Il faut se poser la question d'utilisation de MVC et de POO dans le cas de petites/moyennes applications avec 1 ou 2 développeurs.

Il ne faut pas perdre de vue que développer en MVC et donc généralement avec un framework, demande que le modèle soit parfaitement documenté. Cela demande non plus de savoir coder en Php, mais de maitriser le framework et le modele mvc sur lequel on s'appuie et plus généralement la POO.
J'ai récemment eu à intervenir en task force sur une application conçue sur un framework MVC et ORM d'une société disparue, s'appuyant lui même sur du smarty et du PEAR, sans aucune doc, et là, je ne souhaite cela à personne.

Bilan: Constat de non récupération, évolutions réduites au minimum, et réécriture totale conseillée.

Il est tout aussi impensable d'obliger à faire de la POO que de l'interdire.
Il faut juste être conscient des avantages et des inconvénients qui ont été évoqués tout au long de ce forum.

Bonne journée à tous
Cdt

Excuse moi mais le problème que tu décris n'est pas relatif à la POO. Que le code soit impératif ou OO, il faut qu'il soit bien documenté

Perso, j'espère que PHP tira une croix définitivement sur l'impératif, et typera plus fortement ses variables.

Une raison simple: voir de plus en plus de code PHP dans les entreprises et sur les gros projets, et ne plus trainer "cette réputation de langage pour les bidouilleurs".

10/10/2007, 21h28	#43
Yogui Rédacteur Guillaume Rossolini Directeur technique Inscription : février 2004 Messages : 13 720 Détails du profil Informations personnelles : Nom : Guillaume Rossolini Localisation : France Informations professionnelles : Activité : Directeur technique Informations forums : Inscription : février 2004 Messages : 13 720 Points : 28 975 Points : 28 975	Je te l'accorde, appeler une méthode d'objet comme on appellerait une méthode de classe n'a pas grand intérêt. Sur ce coup, PHP n'est pas encore tout à fait au point. PHP5 a marqué un très grand pas vers un modèle objet idéal, mais nous n'y sommes pas encore Rappelons que PHP est avant tout un langage de script plutôt qu'un langage compilé, et qu'il a tout intérêt à conserver cette optique. __________________ Mes articles - Zend Certified Engineer (PHP + Zend Framework) Ressources PHP - Ressources Zend Framework
	00

11/10/2007, 11h27	#46
zulot Membre éclairé Inscription : décembre 2004 Messages : 662 Détails du profil Informations personnelles : Âge : 30 Localisation : France, Paris (Île de France) Informations forums : Inscription : décembre 2004 Messages : 662 Points : 319 Points : 319	oula on peut pas être a la place du codeur non plus. Ton exemple c'est un peu comme le mec qui fait une boucle infini car il a pas fait attention a sa clause d'arret. Et ca ca n'a rien a voir avec le langage. Le langage a ses expressions et sa syntaxe a respecter apres c'est au codeur de faire attention. __________________ Pour me faire grandir
	00

11/10/2007, 15h34	#54
GrandFather Expert Confirmé Sénior Inscription : mai 2004 Messages : 4 541 Détails du profil Informations personnelles : Âge : 43 Informations forums : Inscription : mai 2004 Messages : 4 541 Points : 6 432 Points : 6 432	Franchement, aborder le développement de grosses applications PHP en faisant l'impasse sur la POO ne me paraît pas raisonnable... A moins d'abandonner toute possibilité de maintenance évolutive. D'autant que si vous adoptez un framework MVC, ce qui est fortement recommandé, l'usage de la POO vous est quasiment imposé. __________________ FAQ XML ------------ « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser » Giacomo Leopardi
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email