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

Langages de programmation Discussion :

La réutilisation dans la POO et ses limitations actuelles


Sujet :

Langages de programmation

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut La réutilisation dans la POO et ses limitations actuelles
    La réutilisation dans la POO et ses limitations actuelles
    Est-il possible d’y remédier ? Que faut-il faire ?

    Au début des années 1990, l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation. Aujourd’hui, Scott Westfall, programmeur et chef de projet, revient sur ce concept et sa situation actuelle dans un billet de blog.

    « Il n’est pas rare de découvrir que plusieurs personnes au sein de votre équipe ont codé essentiellement la même fonctionnalité. Clairement, cela illustre un manque de réutilisation de code efficace ». C’est en ces termes que s’est prononcé Westfall. Mais qu’en est-il réellement de la réutilisation de code ?
    Aux premiers abords, ce concept désigne la réutilisation de code, de classes et des modèles de conception existants au lieu d’en créer des nouveaux. Mais, pour Westfall c’est plus que cela : « Il s’agit plus de l’efficacité du code que de l’efficacité de la programmation ».

    En outre, pour ce professionnel, une compréhension de cette situation passe inévitablement par répondre à certaines questions :

    • Pourquoi les développeurs ne réutilisent pas le code existant ? Le blogueur évoque certaines raisons comme :
      • déterminer les parties réutilisables d’un code est difficile ;
      • le manque de documentation : si les éléments réutilisables ne sont pas documentés, leur utilisation devient plus complexe ;
      • les développeurs ne prennent pas le temps de chercher du code réutilisable ;
      • un élément réutilisable peut altérer le modèle de conception, ce qui implique un rapport avantages/coûts défavorable.
      • l’écriture de code de manière non réutilisable. Ce dernier point nous renvoie directement à la seconde question.

    • Pourquoi les développeurs ne codent pas de manière à réutiliser le code ?
      • Ecrire un code réutilisable demande plus d’efforts.
      • Manque de temps : les développeurs manquent de temps pour écrire un code réutilisable, même si notre blogueur a une vision différente : « En réalité, beaucoup de développeurs arrivent à trouver du temps pour coder quelque chose pour leur propre utilisation, mais n’arrivent pas à en trouver pour ce cas de figure».
      • Bénéfices : à l’heure actuelle, le cycle de vie d’un code est généralement assez court, ainsi, les développeurs ne voient pas les bénéfices d’un code réutilisable.

    Ajouter à cela, les propos de Westfall évoquent un autre facteur justifiant la situation actuelle : « même quand il y a une réutilisation du code décente, la réutilisation des modèles de conception est souvent négligée malgré le meilleur retour sur investissement qu’elle offre ». En effet, la réutilisation des modèles de conception offre beaucoup d’avantages, mais, en contrepartie, une bonne documentation et des templates de code sont nécessaires, ce qui la marginalise.

    Faut-il abandonner la réutilisation à son sort actuel ? Non, malgré ces problèmes, la réutilisation est importante. Quand les choses sont faites correctement, cela n’accélère pas uniquement le développement, mais permet aussi de créer des fonctionnalités qui fonctionnent avec constance au sein d’une application ».

    Alors, quelle est la solution pour y remédier ? Pour Westfall, une approche centrée sur l’architecture et sur sa maintenance en impliquant davantage les développeurs permettrait à ces derniers de les responsabiliser, de mieux reconnaître les éléments réutilisables de leur code et à penser plus à la réutilisation.

    Enfin, Westfall évoque ce qui suit : « si une compagnie est suffisamment grande, vous pouvez dédiés du personnel à la collecte et à la gestion des éléments réutilisables. Je vois ces personnes-là comme étant plus des bibliothécaires que des architectes »

    Source : Billet de blog de Scott Westfall
    Et vous ?

    Que pensez-vous de la réutilisation en POO ?

    Faites-vous souvent appel à la réutilisation en POO ?

  2. #2
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    La réutilisation, c'est bien, mais ce n'est pas aussi simple que repérer des blocs de code en doublon et les extraire dans de nouvelles méthodes/classes, ou se dire que ce truc là-bas ressemble vaguement à ce dont on a besoin et l'utiliser.

    Réutiliser nécessite un gros travail d'abstraction, de découpage et de nommage. Il faut tirer l'essence d'un bloc de code pour mettre un nom précis et adéquat dessus et lui donner un contrat clair, éventuellement distinguer ses différentes responsabilités pour les extraire dans des éléments séparés... C'est une des choses les plus compliquées en programmation.

    Même une fois qu'on a fait ça, réutiliser un composant ne sert à rien si on sait que celui-ci risque de changer pour des raisons totalement indépendantes de notre besoin actuel et de devenir incompatible, ou nous force à rentrer dans un moule qui va apporter de la complexité inutile ou des dépendances non désirées vers d'autres composants.

    Honnêtement, je vois plus souvent du code réutilisé mal à propos, des abstractions mal nommées ou faisant 10 choses + le café, des frameworks dont on n'utilise que 2% des fonctionnalités qu'on se traine comme des boulets, que du code pas assez réutilisé.

  3. #3
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Je suis surpris que personne n'ait mentionné le principal obstacle à la ré-utilisabilité : le système de types et les limites du polymorphisme. Entre les types paramétriques trop peu spécifiques, les langages substituant à l'héritage multiple des interfaces sans code (donc redéfinition obligatoire), les conflits de nommage entre les besoins (l'identifiant de l'un est l'index de l'autre) pas forcément simplifiable grâce à un accesseur (parce qu'il faut un accès par référence), etc, on peut dire que les typages statiques font beaucoup pour empêcher la réutilisabilité. Bien souvent ça se termine avec une usines à gaz de douze classes à la fonction obscure pour réutiliser douze lignes.

    Et si on ajoute à ça les problèmes de performances, le couplage accru, les subtiles différences de comportements, etc, tout ce qui semble a priori intéressant à généraliser ne l'est pas.

    En attendant beaucoup de langages doivent être enrichis.

  4. #4
    Nouveau Candidat au Club
    Inscrit en
    Mars 2004
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 47
    Points : 0
    Points
    0
    Par défaut
    Depuis que j'ai codé cette classe, je gagne un temps juste énorme puisque la plupart des éléments dans la base de données d'un site ont besoin des mêmes traitements : Récupérer, trier, publier ...

    Code php : 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
    34
     
    abstract class ContentNode
    {
    	protected $pdo;
    	protected $nodeTableName;
    	protected $nodeIdName;
     
    	public function ContentNode($pdo,$nodeTableName="",$nodeIdName="")
    	{
    		$this->pdo = $pdo;
    		$this->nodeTableName = $nodeTableName;
    		$this->nodeIdName = $nodeIdName;
    	}
     
    	public function getItemById($id)
    	{
    		$sql="SELECT * FROM ".$this->nodeTableName." WHERE ".$this->nodeIdName."=?";
    		$query=$this->pdo->prepare($sql);
    		$query->execute(array($id));
     
    		return $query->fetch();
    	}
     
    	public function switchItemActivation($item)
    	{
    		$active = 0;
     
    		if($item['actif'] == 0) $active = 1;
     
    		$sql="UPDATE ".$this->nodeTableName." SET actif=? WHERE ".$this->nodeIdName."=?";
    		$query=$this->pdo->prepare($sql);
    		$query->execute(array($active,$item[$this->nodeIdName]));
    	}
    //....

    Tout le problème étant qu'il répéter les mêmes actions un sacré paquet de fois avant de savoir ce qui marche, ce qui ne marche pas et standardiser son propre code pour qu'il puisse coller au plus de cas possible.

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 434
    Points
    434
    Par défaut
    @Luckyluke34 : Pour le coup de réutiliser les codes en doublon, il y a checkstyle qui fonctionne redoutablement bien ! Code dupliqué : Warning.

    Et pour pouvoir réutiliser, je ne suis pas d'accord avec toi. Il ne faut pas tirer l'essence d'un bloc. Il faut que la personne qui a écrit ce bloc ait écrit la doc (javadoc, csdoc, ce-que-tu-veux-doc).

    Le problème dans la réutilisation, c'est qu'il faut une doc, donc il faut que la personne qui écrit le code sous cette doc ait les idées claires sur le contrat de la classe / méthode qu'il est en train d'écrire.

  6. #6
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Que pensez-vous de la réutilisation en POO ?
    C'est un bon principe, mais il faut rester pragmatique ; si rendre le code réutilisable le rend trop complexe, ça ne vaut pas le coup.

    Faites-vous souvent appel à la réutilisation en POO ?
    Autant que possible, oui.

    La plupart du temps, un bout de code non trivial est écrit pour un besoin précis, pas dans l'idée d'être réutilisé. C'est seulement après coup qu'on se rend compte qu'on a besoin de le réutiliser, généralement avec des petites variantes. Dans ces cas là, un petit coup de refactoring permet généralement d'éviter la duplication de code, en ajoutant des paramètres à une méthode ou des dépendances à une classe.

    (ce débat tombe à pic, je suis justement en train de me prendre la tête sur un refactoring pour éviter de dupliquer un bout de logique métier... et je commence à me demander si ça en vaut la peine )

  7. #7
    Membre actif
    Homme Profil pro
    Développeur
    Inscrit en
    Décembre 2008
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Décembre 2008
    Messages : 101
    Points : 256
    Points
    256
    Par défaut
    AMHA le problème principal est un problème de modélisation. Il n'est pas simple de savoir comment découper son travail pour le rendre réutilisable ou du moins il est compliqué de savoir quand est-ce que ça va être utile. Le fait de s'obliger de tester unitairement son code aide beaucoup à créer des parties réutilisables (puisqu'elles sont de fait utiliser en production et dans les tests).

    Il y a des principes qui restent à mon avis pas assez connus :
    • créer des packages par fonctionnalités et pas par couche
    • éviter les effets de bord comme la peste
    • penser son code comme une API
    • découper son code et utiliser de l'injection de dépendance

  8. #8
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 167
    Points : 4 647
    Points
    4 647
    Par défaut
    Rendre réutilisable du code peut parfois demande tellement temps que s'il n'est pas réutiliser plus de 3-4 fois, ça peut aller plus vite d'adapter, puis si besoin réel de refaire une refacto. Si on doit tout anticiper on ne s'en sort plus, le temps n'est pas infini...

  9. #9
    Membre actif
    Homme Profil pro
    Développeur
    Inscrit en
    Décembre 2008
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Décembre 2008
    Messages : 101
    Points : 256
    Points
    256
    Par défaut
    Citation Envoyé par Zefling Voir le message
    Rendre réutilisable du code peut parfois demande tellement temps que s'il n'est pas réutiliser plus de 3-4 fois, ça peut aller plus vite d'adapter, puis si besoin réel de refaire une refacto. Si on doit tout anticiper on ne s'en sort plus, le temps n'est pas infini...
    Il y a des choses facilement réutilisables qui ne le sont que rarement (de mon expérience).
    Si déjà c'était fait pour ce genre de choses ça irait déjà mieux.

    J'ai même vu des duplications de code simplement par mauvaise modélisation objet (mal connaissance du polymorphisme, de son intérêt et de comment l'obtenir). Je travail avec des langages qui n'ont pas de traits et je me demande si ça ne serait pas plus simple pour certains de faire de la réutilisation à base de traits plutôt qu'avec de l'héritage.

  10. #10
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par Arsene Newman Voir le message
    Que pensez-vous de la réutilisation en POO ?
    La question à se poser, c'est plutôt : Quelles sont les techniques de réutilisation en POO ?

    • définir un template / Generic pour appliquer un même algorithme / une même structure de données à des types différents ?
    • utiliser l'héritage, la surcharge et le polymorphisme pour créer une nouvelle classe avec un comportement différent ? (d'où la multiplication à outrance du nombre de classes)
    • utiliser un pattern Strategy ou Template Method ?


    Désolé, mais c'est plutôt limité...



    À l'inverse, la programmation fonctionnelle a une certaine tendance à promouvoir la réutilisabilité :

    • fonction d'ordre supérieure : on définit une fonction f qui prend une fonction g en paramètre. f définit l'algorithme général et g un comportement spécifique de cet algorithme. L'écriture de code consiste souvent à assembler des fonctions d'ordre supérieur avec d'autres fonctions
    • "partial application" : on définit une fonction f avec un comportement générique (dans le sens où elle peut faire beaucoup de choses différents suivant les paramètre), puis on la "spécialise" en fixant un ou plusieurs de ses paramètres, ce qui nous donne une nouvelle fonction g
    • inférence de type : j'ai une fonction de type ('a -> 'a -> 'a), je lui passe un entier et ça devient une fonction de type (int -> int -> int); comme les templates / Generics, mais la syntaxe en moins...


    Au bout d'un moment, écrire des fonctions aussi génériques que possible, ça devient presque une seconde nature ! (et on essaye de transposer ça en POO).

    D'ailleurs, en POO on y vient gentiment avec les délégués, les lambdas... mais on sent bien que c'est pas aussi naturel qu'en programmation fonctionnelle, ne serait-ce qu'au niveau de la syntaxe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    public static T DoSomeStuff<A, B, T>(System.Funct<A, B, T> f, A a, B b) { ...
    
    // Au lieu de:
    // let doSomeStuff f a b = ...


    Citation Envoyé par Arsene Newman Voir le message
    Au début des années 1990, l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation.
    En fait, le principal argument de la POO, c'était surtout l'encapsulation.
    Pour caricaturer, le fait de pouvoir représenter certains concepts en les rangeant dans des petites boites (les classes) afin de produire de joli diagrammes UML, ça faisait plaisir aux décideurs qui ne mettent jamais le nez dans le code.


    Autre facteur non négligeable : ces concepts de classes semblent assez naturels et simples à appréhender (du moins au début...), donc que on s'est dit que ce serait plus facile de former de la main d'oeuvre dans ce domaine.

    Du coup, l'industrie s'est rendu compte que ça arrangeait tout le monde :
    - les managers / concepteurs / architectes s'échangent des jolis diagrammes UML (qu'on compile dans des documents appelés "specs")
    - on dispose de millions d'Indiens pour transformer ces specs en code

    C'est comme ça que la POO est devenue le paradigme de facto dans l'industrie (parce que ça permet de communiquer des idées, souvent les mêmes, à du personnel considéré comme parfaitement interchangeable; pas parce que ça permet la réutilisation du code).

    Parce que les méthodes de réutilisation de code en POO, c'est pas l'idéal.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  11. #11
    Expert confirmé
    Inscrit en
    Avril 2008
    Messages
    2 564
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 564
    Points : 4 438
    Points
    4 438
    Par défaut
    C'est un vieux debat depuis la naissance de la POO...

    Djiskra disait que cette idee ne pouvait naitre qu'en Californie....

    Entendaient par là ,qu'elle vise comme le "Fordisme" à standardiser la production de code...pour la production en serie....

    L'esprit americain ayant invente le "standard industriel",le "module"....
    Tout le reste n'est que discussion de details pour developpeurs....

  12. #12
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    La question à se poser, c'est plutôt : Quelles sont les techniques de réutilisation en POO ?
    Dommage que la densité de trolls par ligne soit aussi élevée dans ton message car le fond était plutôt intéressant, la programmation fonctionnelle ayant en effet un très net avantage dans la réutilisabilité des algorithmes élémentaires. Mais reléguer le polymorphisme a un simple prétexte pour faire de jolis diagrammes, c'est quand même mépriser son intérêt dans les systèmes réels : la programmation fonctionnelle montre ses limites quand il te faut passer dix arguments ou recourir à des mécanismes tordus pour résoudre un problème où le polymorphisme est la bonne réponse.

    Les deux paradigmes sont nécessaires et doivent cohabiter dans un même langage. C'est de plus en plus souvent le cas.

  13. #13
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 545
    Points : 2 084
    Points
    2 084
    Par défaut
    Je crois que les bonnes conceptions basées fortement sur les design pattern aident aussi grandement à réutiliser son code. Une équipe qui bosse toujours avec les patterns reconnait directement le cas et se souvient du code déjà utilisé. Je ne parle pas juste en matière de conception pour les architectes, concepteurs .., mais ceux là pourront aussi facilement orienté le développeur à ne pas reprendre du code déjà existant, mais du code existant lors de l’implémentation déjà faite d'un pattern donné est facilement réutilisable.

    Le problème c'est qu'en matière de conception beaucoup de gens tu va trouver qu'ils vont développés avec des langages objets et se font par exemple à des spécifications techniques du code écris manuellement en non pas en pure POO avec des digrammes UML, n'en parlons pas du code des squelettes déjà généré et une documentation du code avant même le codage des méthodes elles même.

    Et quand ils font des diagrammes de class ils s'intéressent beaucoup plus à la conception de la partie model(entités) et non pas l’application en sa totalité qu'elle respecte un model vraiment à la POO bien basé sur des patterns.

    J'étais aussi étonné d'une personne avoir un jour commenté dans de forum qu'en cas de génération de code, le code généré là en général ne sert à rien après il sera jeté, et ben je dis que soit le générateur ne génère pas quelque chose qui enchante le compilateur à 100%, soit vous ne savez pas vraiment comment s'en servir. C'est plutôt un gain de temps en programmation.

    A titre de rappel qu'il y a des gens qui font des applications qu'avec des conceptions UML, et l'application est généré à 100% sans avoir à toucher quoi que ce soi dans le code, et il n y a même pas besoin de faire de test comme les testes unitaires, et autres fin de s'assurer si ça marche ou pas, non: tester c'est utiliser. Il y a bien sûr qu'il a un boulot aussi formels dedans.

    Donc je reviens à dire que le fait que l'application ne soit pas sérieusement bien conçu contribue à une limite sur la réutilisation du code et la réutilisation est un travail qui se rend facile avec la collaboration de tous les membres de l'équipe.

    Citation Envoyé par DonQuiche Voir le message
    Je suis surpris que personne n'ait mentionné le principal obstacle à la ré-utilisabilité : le système de types et les limites du polymorphisme. Entre les types paramétriques trop peu spécifiques, les langages substituant à l'héritage multiple des interfaces sans code (donc redéfinition obligatoire), les conflits de nommage entre les besoins (l'identifiant de l'un est l'index de l'autre)
    +1.
    Certes c'est une grande limite dans les interfaces. Depuis les années 90 on nous définit qu'une interface n'a que des signatures de méthodes et possible de d'en hériter de plusieurs mais l’implémentation du corps de chaque méthode est obligatoire une fois dans la classe.

    Par contre on voit maintenant Java dans sa dernière version 8 vient d’évoluer dans ce sens introduisant la notion d’implémentation par défaut d'une méthode d'interface, ce qui contribue grandement à la factorisation des méthodes et à la réutilisation du code sans souci.

    Ainsi j’aurais aimé que cette notion d’implémentation par défaut des méthodes d'une interface se standardise comme la notion même d'interface.

    Dans le moment qu'il faut signaler seulement que tu hérite de telle interface tu n'a pas besoin de définir le core et tu encore as devant toi l'héritage multiple et des techniques de gestion de conflit de nom. Donc il faut que cette notion soit répandu dans les autres langages comme la notion même d'interface, ça va bien contribuer grandement à la réutilisation du code.

    Même si en réalité cette notion fut introduite pour les besoin d’extension sans toucher aux implémentations existantes, mais un grand avantage se pressente sur les nouvelle applications et les application futures et surtout aux concepteur d'API.

    Là je profite l'occasion pour partager mon avis aux concepteurs qui ciblent Java 8, de même que les développeurs, en guise de rappel (je n'ai pas de leçon à donné à qui que se soit) qu'il y a actuellement une piste d'améliorer aussi la manière de conception et de développement, quand on a une méthode qui définit un comportement sur un objet indépendamment de son état il faut la coder dans une interface dans une méthode par défaut et en hériter. Du coup, une réutilisation totale prochainement sans modification.

    Avec la possibilité aussi de manipuler des méthodes purement virtuelles dans cette implémentation par défaut et la possibilité aussi dans un cas particulier d'apporter quelques modification en cas de besoin dans une implémentation spécifique de la méthode dans la classe, et du polymorphisme à la portée . Comme j'ai dis dans la possibilité d'en hériter de plusieurs sans souci.

  14. #14
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    Citation Envoyé par Arsene Newman Voir le message
    Enfin, Westfall évoque ce qui suit : « si une compagnie est suffisamment grande, ... »
    Je crois que tout est dit ici. Le problème, ce ne sont pas les développeurs, ce sont les moyens, et encore.

    En même temps je ne crois pas aux bibliothèques qui font le café. Chaque cas est particulier, et si une bibliothèque était capable de gérer tous les cas de figure avec les performances et la portabilité maximale, cela se saurait. Et on ne discuterait pas de cela ici.

    Mais bon, responsabiliser le développeur qui travaille déjà 10 heures par jour, faut en vouloir. Le management n'a pas de limite visiblement.

  15. #15
    En attente de confirmation mail

    Profil pro
    Inscrit en
    Septembre 2013
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2013
    Messages : 639
    Points : 2 347
    Points
    2 347
    Par défaut
    Je ne trouve pas qu'il est plus facile d'écrire du code réutilisable dans le paradigme impératif objet que dans le paradigme impératif procédural.

    De toute façon, l'objet, on en reviendra bien un jour... c'était fait pour simplifier les choses et il se produit souvent tout le contraire. J'estime qu'il n'y a pas dix pourcents des problèmes qui sont plus faciles à résoudre en objet qu'en procédural ; aussi si plus de dix pourcents du code d'une application est "objet", c'est suspect.

    Je trouve qu'on essaye souvent d'écrire du code réutilisable, qu'on se fait beaucoup ch... pour ça, et qu'en général on constate quelques années plus tard que cela n'a servi à rien. Soit le code n'est pas si réutilisable que prévu, soit on n'a pas besoin de le réutiliser.

    Ecrire du code réellement réutilisable est une des taches les plus difficiles auxquelles un programmeur peut être confronté. Après de longues années d'expérience on commence à atteindre cet objectif relativement souvent (la définition de "souvent" dépendant sans doute de chacun). Mais c'est assurément quelque chose qu'aucune formation ne peut enseigner.

  16. #16
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2012
    Messages
    17
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2012
    Messages : 17
    Points : 59
    Points
    59
    Par défaut
    L'avantage, c'est vu que tu as centralisé l'accès à tes données, tu peux directement corriger une injection SQL potentielle :

    Code php : 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
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    abstract class ContentNode
    {
    	protected $pdo;
    	protected $nodeTableName;
    	protected $nodeIdName;
     
    	private function EscapeAttributeName($attr_name)
    	{
    		return /* XXX To Implement */;
    	}
     
    	private function EscapeTableName($table_name)
    	{
    		return /* XXX To Implement  */;
    	}
     
    	public function ContentNode($pdo,$nodeTableName="",$nodeIdName="")
    	{
    		$this->pdo = $pdo;
    		$this->nodeTableName = $nodeTableName;
    		$this->nodeIdName = $nodeIdName;
    	}
     
    	public function getItemById($id)
    	{
    		$sql="SELECT * FROM ". $this->EscapeTableName($this->nodeTableName) ." WHERE ".$this->EscapeAttributeName($this->nodeIdName)."=?";
    		$query=$this->pdo->prepare($sql);
    		$query->execute(array($id));
     
    		return $query->fetch();
    	}
     
    	public function switchItemActivation($item)
    	{
    		$active = 0;
     
    		if($item['actif'] == 0) $active = 1;
     
    		$sql="UPDATE ".$this->EscapeTableName($this->nodeTableName)." SET actif=? WHERE ".$this->EscapeAttributeName($this->nodeIdName)."=?";
    		$query=$this->pdo->prepare($sql);
    		$query->execute(array($active,$item[$this->nodeIdName]));
    	}
    //....

    C'est bien la peine d'utiliser l'overhead de PDO pour laisser passer ça

  17. #17
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    Tien moi aussi j'ai fait ma propre classe en PHP pour le traitement des base de données, un code que je réutilise tout le temps
    et qui me fait gagner bien du temps avec un résultat bien plus modulable qu'avec pdo seul

    Sinon pour la réutilisation de code il faut juste voir quels sont les parties que l'on à besoins de réutiliser souvent et l'on en fait des classe
    Rien, je n'ai plus rien de pertinent à ajouter

  18. #18
    Nouveau Candidat au Club
    Inscrit en
    Mars 2004
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 47
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Lupus Michaelis Voir le message
    L'avantage, c'est vu que tu as centralisé l'accès à tes données, tu peux directement corriger une injection SQL potentielle :

    C'est bien la peine d'utiliser l'overhead de PDO pour laisser passer ça
    Je n'y avais pas pensé, mais cette variable n'est de toute manière attribuée que dans mon code en dur et ne peut pas être attribuée dynamiquement par une variable $get par exemple. Si quelqu'un arrive à la modifier, c'est que rien ne l'empêche d'aller mettre sa propre requête complète

  19. #19
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 679
    Points
    1 679
    Par défaut Plutôt au niveau de la conception
    Au niveau du code il sera toujours difficile de détecter les duplications : du code légérement diffférent peut faire la même chose (même si des outils comme checkstyle peuvent aider).

    Les créateurs de Feature-Driven Development (FDD) ont mis l'accent sur la conception, le modèle.
    En effet, au niveau de la modélisation la réutilisation est effectivement beaucoup plus aisée, la duplication plus claire et le code résultant plus propre.

  20. #20
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    Dommage que la densité de trolls par ligne soit aussi élevée dans ton message car le fond était plutôt intéressant,
    Merci.

    Citation Envoyé par DonQuiche Voir le message
    la programmation fonctionnelle ayant en effet un très net avantage dans la réutilisabilité des algorithmes élémentaires.
    C'est clair.

    Aussi, quand je lis "l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation", je trouve que c'est un peu exagéré (limite trollesque), d'où ma réponse (pas mal exagérée, je l'admets).

    Après je ne dis pas qu'il faut tout jeter pour faire de la programmation fonctionnelle, mais juste que de s'essayer à d'autres paradigmes permet de voir d'autres manières de penser. Même si on ne voit pas le bénéfice immédiat, ça a un effet positif sur notre manière d'appréhender certains problèmes (ex : la question de la réutilisabilité).
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

Discussions similaires

  1. Réponses: 27
    Dernier message: 19/09/2006, 10h51
  2. Valeur des formulaire réutilisées dans des requètes SQL.
    Par cotmar dans le forum Requêtes et SQL.
    Réponses: 6
    Dernier message: 09/05/2006, 11h16
  3. Notion de réutilisation dans la programmation
    Par housni dans le forum Langages de programmation
    Réponses: 13
    Dernier message: 04/04/2006, 16h09
  4. Réponses: 4
    Dernier message: 15/03/2006, 12h22
  5. Réponses: 5
    Dernier message: 27/11/2005, 23h07

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