Astuce php pour éviter d’avoir à se palucher plein de getters/setters pour des classes de stockage.
via Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage.
Ou alors revenir à la raison dans certains cas et ne pas appliquer les concepts de la POO façon recette de cuisine vaseuse sans prendre de recul. Par exemple pour des DTO ça ne sert strictement à rien selon moi de persister à utiliser des getters / setters. Mais alors à rien du tout ! Pire c’est contre productif à tous les niveaux.
Les DTO sont des objets destinés uniquement à stocker de la donnée. Aucune intelligence dedans. Pire, quand on fait du getter / setter dans un DTO on apporte même pas d’API et de stabilité dans les évolutions puisque les getters / setters sont nommés en fonction des données associées et donc le nom de ces méthodes est largement aussi peu stable que les attributs associés… Sans compter les cas ou les valeurs derrière ne sont même pas protégées puisqu’il y a des passages par référence des objets (cas pas assez souvent abordé en java selon moi).
Pire encore en terme de performance ! Utiliser du getter / setter à tarbasse dans certains cas (ici le DTO) est juste une immondice de performance. Ne pas oublier que quand vous concevez une méthode et l’utilisez l’interpréteur / la machine effectue un branchement / débranchement de l’exécution pour faire l’appel (sauf dans certains cas ou des optimisations sont possibles par le compilateur). Or c’est un processus qui prend du temps par rapport a une exécution séquentielle… Imaginez ça multiplié par le nombre de champs et d’enregistrements…
Et das certains cas (dans ce lien) on se retrouve a écrire des systèmes dégeu de génération dynamique des getters / setters, ce qui est largement aussi moche et prend du temps tout ça pour éviter une flemme d’écriture de code.
Bref, ne pas appliquer les recettes de cuisine brutos et prendre du recul est salvateur. Par exemple, dans le cas d’une DTO, arrêtez de continuer avec vos attributs privés et des getters / setters de merde. Passez simplement vos attributs en public ! Vous gagnez en temps d’exécution (accès mémoire only), vous gagnez en lisibilité et maintenance du code (attributs only) et vous ne perdez rien au passage…
Si vous ne me croyez pas je vous cite un bout de doc officielle de la javadoc (mais je pense que c’est applicable d’une manière générale).
http://www.oracle.com/technetwork/java/transferobject-139757.html
Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods.
Bon après j’ai longtemps fait des getters / setters sur des DTO avant de penser ainsi.
Attention je parle bien de tout cela dans le cadre des objets de données purs, ne pas mélanger mes propos avec des classes définissant une API ou une intelligence métier.