IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

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


Sujet :

Langage PHP

  1. #41
    Membre à l'essai
    Inscrit en
    Octobre 2007
    Messages
    11
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 11
    Points : 13
    Points
    13
    Par défaut
    Citation Envoyé par jpsoft Voir le message
    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 !


  2. #42
    Membre du Club
    Profil pro
    Développeur
    Inscrit en
    Avril 2007
    Messages
    52
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2007
    Messages : 52
    Points : 58
    Points
    58
    Par défaut
    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.

  3. #43
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    Février 2004
    Messages
    13 721
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : Février 2004
    Messages : 13 721
    Points : 29 985
    Points
    29 985
    Par défaut
    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.

  4. #44
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 70
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 9
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par pot2yaourt Voir le message
    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

  5. #45
    Membre habitué Avatar de ludosoft
    Homme Profil pro
    Chef de projet technique
    Inscrit en
    Juillet 2002
    Messages
    99
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2002
    Messages : 99
    Points : 136
    Points
    136
    Par défaut
    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...
    Et un d'plus en moins !

  6. #46
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    691
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Décembre 2004
    Messages : 691
    Points : 362
    Points
    362
    Par défaut
    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.

  7. #47
    Membre habitué
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 181
    Points : 162
    Points
    162
    Par défaut
    Citation Envoyé par pot2yaourt Voir le message
    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.
    PhpMyObject teck leader
    http://pmo.developpez.com

    La justice de l'intelligence est la sagesse. Le sage n'est pas celui qui sait beaucoup de choses, mais celui qui voit leur juste mesure.

  8. #48
    Membre du Club
    Profil pro
    Développeur
    Inscrit en
    Avril 2007
    Messages
    52
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2007
    Messages : 52
    Points : 58
    Points
    58
    Par défaut
    Citation Envoyé par jpsoft Voir le message
    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.

  9. #49
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 70
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 9
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par code34 Voir le message
    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

  10. #50
    Membre habitué
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 181
    Points : 162
    Points
    162
    Par défaut
    Citation Envoyé par jpsoft Voir le message
    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 !!!
    PhpMyObject teck leader
    http://pmo.developpez.com

    La justice de l'intelligence est la sagesse. Le sage n'est pas celui qui sait beaucoup de choses, mais celui qui voit leur juste mesure.

  11. #51
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 70
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 9
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par pot2yaourt Voir le message
    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

  12. #52
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 70
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 9
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par code34 Voir le message
    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

  13. #53
    Membre habitué Avatar de ludosoft
    Homme Profil pro
    Chef de projet technique
    Inscrit en
    Juillet 2002
    Messages
    99
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2002
    Messages : 99
    Points : 136
    Points
    136
    Par défaut
    Citation Envoyé par zulot Voir le message
    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 ?
    Et un d'plus en moins !

  14. #54
    Expert éminent
    Avatar de GrandFather
    Inscrit en
    Mai 2004
    Messages
    4 587
    Détails du profil
    Informations personnelles :
    Âge : 54

    Informations forums :
    Inscription : Mai 2004
    Messages : 4 587
    Points : 7 103
    Points
    7 103
    Par défaut
    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

  15. #55
    Membre habitué
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 181
    Points : 162
    Points
    162
    Par défaut
    Citation Envoyé par GrandFather Voir le message
    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 !
    PhpMyObject teck leader
    http://pmo.developpez.com

    La justice de l'intelligence est la sagesse. Le sage n'est pas celui qui sait beaucoup de choses, mais celui qui voit leur juste mesure.

  16. #56
    Expert éminent
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    Février 2005
    Messages
    3 486
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : Février 2005
    Messages : 3 486
    Points : 6 027
    Points
    6 027
    Par défaut
    Citation Envoyé par GrandFather Voir le message
    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?
    Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...

  17. #57
    Membre à l'essai
    Inscrit en
    Octobre 2007
    Messages
    11
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 11
    Points : 13
    Points
    13
    Par défaut
    Citation Envoyé par code34 Voir le message
    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

  18. #58
    Membre habitué
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 181
    Points : 162
    Points
    162
    Par défaut
    Citation Envoyé par TIman Voir le message
    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);
    PhpMyObject teck leader
    http://pmo.developpez.com

    La justice de l'intelligence est la sagesse. Le sage n'est pas celui qui sait beaucoup de choses, mais celui qui voit leur juste mesure.

  19. #59
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 70
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 9
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par GrandFather Voir le message
    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

  20. #60
    Membre habitué
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    181
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 181
    Points : 162
    Points
    162
    Par défaut
    Citation Envoyé par jpsoft Voir le message
    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".
    PhpMyObject teck leader
    http://pmo.developpez.com

    La justice de l'intelligence est la sagesse. Le sage n'est pas celui qui sait beaucoup de choses, mais celui qui voit leur juste mesure.

Discussions similaires

  1. [PHP 5.0] La programmation orientée objet en PHP
    Par RideKick dans le forum Langage
    Réponses: 12
    Dernier message: 28/06/2011, 18h01
  2. [MySQL] Programmation orienté objet en php 5
    Par dhbmedanis dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 06/05/2011, 11h06
  3. Programmation orientée objet en PHP
    Par dekalima dans le forum Langage
    Réponses: 2
    Dernier message: 28/03/2011, 13h45
  4. Réponses: 26
    Dernier message: 12/10/2010, 07h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo