Hello à tous,
 
  Je développe depuis 15 ans en php, et j'ai parfois un peu de mal avec les nouvelles méthodes de dev
 
  J'essaie surtout de savoir si ces nouveautés qui arrivent régulièrement, sont pertinentes à être utilisées. Car une nouvelle techno peut être fun, mais très mauvaise à terme si mal utilisées.
 
  Là je découvre les Services, issue du monde de symfony (bien que nous utilisons zend expressive). Je travail avec des développeurs qui veulent mettre des services partout (forcément ils viennent du monde de symfony 2).
 
  Sur le papier ca semble beau, mais j'ai l'impression que c'est un peu comme coder avec des variables global, mais avec des objets
 
  Vous en pensez quoi ? le débat est ouvert.
 
Merci
 
Pierre

Je ne développe pas avec Symfony, du coup, je suis allé voir ce qu'étaient les services : https://openclassrooms.com/courses/ [...] t-creation
 
Bon, ben, je vois pas la différence avec le design pattern Singleton et ce que ce genre de service apporte de plus
 
Par contre, non, ce ne sont pas des variables globales (tout comme le singleton) : c'est plus propre.

info que j'ai obtenu par t'chat avec un ami  
---
 ça dépend.Mais pour faire simple, un service est utile pour des trucs un peu touchy genre une connexion à la bdd ou alors pour des trucs à mutualiser comme l'appel à un code qui va chercher un avatar gravatar.
 
En clair : Code utilisé à plusieurs endroits, ça veut le coup de faire un service. Code utilisé spécifiquement dans une page, pas besoin d'un service.
---
 
Si y'a d'autre avis ils sont les bienvenues

N'empêche, l'explication donnée ne répond pas à ma question sur l'intérêt par rapport à un singleton. Dans mes applis, j'utilise un singleton pour gérer la connexion à la BD.

un singleton c'est "old school" un service c'est plus récent donc forcément mieux

Nan mais sérieusement, une vrai explication.

je sais pas encore, j'en saurais plus vendredi, après une réunion justement avec les "jeunes" qui doivent me convaincre d'utiliser des services au lieu d'instance classique.
 
Surtout que le code n'a nullement besoin de singleton, au contraire un jour on aura besoin de plusieurs instances d'un même objet. Mais ca ils ne l'ont peut être pas imaginé encore.

Je ne savais pas que ça pouvait s'appeler comme ça mais c'est le genre de truc que j'utilise.
Dans les faits un conteneur de service, c'est juste un objet qui en contient d'autres qui sont appelables par leur nom. On choisit des noms courts sans contraintes par rapport aux noms des classes utilisées, tout est bien nommé, bien rangé, c'est propre.
Le conteneur de services ne dure que l'exécution du script mais permet une persistance des objets qui ne sont initialisé qu'une fois (ce que fait le pattern singleton).
La différence avec les singletons c'est qu'on peut avoir autant de conteneur de service que l'on veut.
Dans la pratique, on utilise qu'un seul conteneur dans toute l'application (ce qui peut faire penser que ce n'est pas plus utile qu'un simple singleton).
Le conteneur de service peut offrir d'autres fonctionnalités que la simple instanciation comme des mécanismes de configuration unifié lors de l'initialisation d'un service (juste après l'instanciation de l'objet).
Et le conteneur de service fait indirectement du pattern factory, cela permet de ne pas avoir de déclaration de namespaces au niveau de l'implémentation. Ça minimise le nombre de ligne à retoucher en cas de renommage de namespace, de changement de librairie etc.
 
Un cas de bad practise : il est possible de mettre un conteneur de service en singleton.
 

 
Un conteneur de service correctement conçu permet d'avoir plusieurs instances d'une même classe mais configurés/initialisés différemment. S'il existe une autre contrainte, c'est que le conteneur de service ne répond pas au besoin et donc il ne faut pas l'utiliser pour cet usage.