IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

[Actualité] Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ?

Noter ce billet
3 Commentaires
par
autran
, 05/06/2016 à 12h27 (1739 Affichages)
Je viens d'analyser le back-end de trois applications web en production qui ont été développées sur la plate-forme JAVA ou JavaScript. J'ai mené cette analyse et cette revue de code à travers un prisme d'identification des bonnes pratiques de l'orienté objet. J'y ai notamment recherché les patterns de conception ou même tout simplement l'utilisation des principaux paradigmes à la base de l'objet.

J'y ai bien retrouvé les patterns Singleton Facade, etc. Mais à ma grande surprise, je ne les ai pas retrouvés où je m'y attendais. En effet, JPA impose bien au développeur de créer un EntityManagerà partir d'un EntityManagerFactory, mais cette implémentation du pattern Factory n'est qu'une utilisation standard de JAVA qui ne demande aucune compréhension des modèles de conception ni des bonnes pratiques du génie logiciel. On va dire que tel monsieur Jourdain, le développeur fait du design pattern sans le savoir.

Le dépouillement de cette campagne de lecture du code source JAVA aboutit au constat que la plupart des héritages et implémentations d'interfaces sont en stricte application des Frameworks structurant de JEE et particulièrement celui de la couche EJB. Je n'ai durant cette lecture repéré qu'une collection d'objets qui utilise astucieusement un héritage et une injection de référence dans le constructeur.
La même campagne menée sur le code JavaScript souligne le même phénomène. J'ai d'ailleurs remarqué que dans la mesure où la couche de mapping entre la base de données et Node.js (Mongoose, Sequelize...) est moins orthodoxe que celle des célèbres EJB, les développeurs développent des talents DBA.

À la lumière de cette analyse, que je n'ai pas réalisée sur une population suffisamment significative, je ne peux m’empêcher de me demander si aujourd’hui développer n'est pas essentiellement comprendre le besoin fonctionnel et le satisfaire avec des frameworks et API de haut niveau.

Je serais même tenté de dire qu'il y a deux types de développeurs :
  • ceux qui comprennent le besoin du client et y répondent très vite au prix d'une veille permanente sur les frameworks ;
  • ceux qui développent ces frameworks en entretenant leur maîtrise des design-pattern de conception.

Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Viadeo Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Twitter Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Google Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Facebook Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Digg Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Delicious Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog MySpace Envoyer le billet « Le développement Objet moderne nécessite-t-il d'en connaître les arcanes ? » dans le blog Yahoo

Mis à jour 06/06/2016 à 06h01 par ClaudeLELOUP

Catégories
Sans catégorie

Commentaires

  1. Avatar de kolodz
    • |
    • permalink
    L'approche est un peu réductrice. Mais, je pense que c'est plus pour incité à la réaction que pour exprimer un avis propre.

    Pour ma part, il est rare que le client débarque avec un besoin impliquant une grande complexité métier. Et les rares cas où cela se produit, il le besoin est revue pour simplifier la vie de tout le monde. Sinon, ça finit en usine à gaz que personne ne sait utiliser ou maintenir.

    Pour rejoindre autran dans sa conclusion, il y a deux types de valeurs "ajoutées" dans notre métier :
    • L'expertise métier
    • L'expertise technique

    Il suffit de ne pas être trop mauvais dans l'une ou l'autre pour avoir un place dans l'industrie. (C'est mieux si c'est celle qui corresponds au poste occupé )

    Cordialement,
    Patrick Kolodziejczyk.
  2. Avatar de autran
    • |
    • permalink
    Oui attention que l'on ne se méprenne pas !
    Ces développeurs qui utilisent les frameworks sans ingénier de modèles de conception objet donnent pleinement satisfaction au client. Et par ailleurs, leur code source était propre, testé et bien documenté.
    Mon jugement reste que se sont des professionnels respectables.

    Je m'étonne juste du décalage entre :
    • les théories du développement objet qui fleurissent et nous pousserait à croire que pour développer bien il faut faire de l'IOC et connaitre sur le bout des doigts les patterns du GOF
    • La réalité du code source en production qui ressemble plus à un Lego dont les briques sont des frameworks.
  3. Avatar de Gnuum
    • |
    • permalink
    J'arrive après la bataille mais j'ai trouvé l'article intéressant et ai eu envie de ramener ma fraise donc!

    Je serais même tenté de dire qu'il y a deux types de développeurs
    Tu oublies les random codeurs et les copy/paste codeurs!

    Personnellement, je pense qu'on ne peut pas exploiter les technologies à leur plein potentiel sans comprendre les principes qui ont conduit leur architecture.
    De plus, les bonnes pratiques (qui vont au delà des simples design patterns) sont indispensables pour avoir un code évolutif, maintenable et testable.

    Pour ma part, il est rare que le client débarque avec un besoin impliquant une grande complexité métier. Et les rares cas où cela se produit, il le besoin est revue pour simplifier la vie de tout le monde. Sinon, ça finit en usine à gaz que personne ne sait utiliser ou maintenir.
    Les design patterns servent justement dans ce genre de cas pour empêcher la divergence de complexité (en minimisant les dépendances entre composants notamment). L'art de l'architecture est la capacité à gérer cette problématique. En tout cas, tu as de la chance que le client accepte de simplifier son besoin! Moi, ça ne m'arrive jamais..

    troll ps: le singleton est un anti-pattern: vive la SOA!