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.