Service Container/Locator is still a global variable and hence it suffers all things related to global variables. We have DI, and DI solves this much better, so we are not forced to use Service Locator.

Do you think the Service Container is that bad? A function or a method where all our helper object instances are stored.

http://symfony.com/doc/2.0/book/service_container.html

What do you think about it?

http://stackoverflow.com/questions/1812472/in-a-php-project-how-do-you-store-access-and-organize-your-helper-objects/1812499#1812499

Thanks you so much

I am not proposing to have more instances or consume memory. Whether you write you application with Global state (Singleton) or with dependency injection (where you have single instance of a class). You have the same number of objects and hence the same memory consumption. The question at the table is not how many instances of objects you have as that is fixed by the application design, but how do these objects get to where they need to be: 1) Global state (bad) or 2) passed in through the constructor (good)

this is a very strange question, since the performance of application has nothing to do wether you have a singleton or not. In both case you have same number of objects, the question is not how many objects you have or what is the performance, but how do the references of the objects get to where they need to be. A) Global state, B) passed in through constructor.

So depending on the language singleton might be the best way to increase application speed while making testing more difficult. (I’m thinking of a logging or caching class here).

However, it is also a waste of memory to keep objects in memory when they are not needed – which is what a singleton does and, as you state, it also make the code much more spooky than it needs to be.

So I can’t quite give up the idea of all losing all singletons (in PHP) but they defiantly shouldn’t be the norm.