Static Factory Class Functions/Dependency Injection/Singletons

[SchweppesAle]

Was just wondering why some people choose NOT to make use of static functions when initializing objects via Factory Classes/Containers.

 

What are the benefits of initializing the Factory class when for all intensive purposes, it's only used to initialize new classes, etc? 

Does this have any impact on Dependency Injection?  I'm assuming that it doesn't since that would defeat the purpose.

 

---------

 

Also, I've noticed that there seems to be an intense stigma within the development community in regard to singletons. 

Are singletons necessarily a bad thing? 

 

What about database objects? 

 

One argument I've heard is that this can often impact the flexibility of your application in the event that a new instance of said class needs to be initialized(a second completely separate connection).

 

However, I was thinking that you could simply store these objects within a static member variable in the factory class; leaving the Database Class' __construct public in the event that you need to create that second/third/fourth connection.

 

Wouldn't this resolve the issue? 

[trq]

Was just wondering why some people choose NOT to make use of static functions when initializing objects via Factory Classes/Containers.

 

What are the benefits of initializing the Factory class when for all intensive purposes, it's only used to initialize new classes, etc?

 

Some people don't brush there teeth, it doesn't mean it a good idea. Using static methods in a pattern like that of the factory is a perfectly valid design decision in my point of view.

 

Also, I've noticed that there seems to be an intense stigma within the development community in regard to singletons. 

Are singletons necessarily a bad thing?

 

The problem with singletons is it's far too tempting to simply use them from within other objects, thus tightly coupling them together. Dependencies should always be injected.

[xyph]

I think forcing a class to be singleton is removing functionality. In a sense, it's almost removing the point of objects in the first place. An argument can be made that PHP already has the ability to create global 'methods' (functions) and 'properties,' (constants) so why make a class to do it?

 

From what I understand, there's plenty of large, open-source projects that use static factory methods. I'd imagine it's mostly preference here.

 

As far as the database class goes, your solution is exactly what I would implement. There's nothing wrong with having a default connection.

 

$db = new dbClass( 'mysql','host','user','pass','port' ); would start a new mysqli connection

$db = new dbClass(); would return an instance using a pre-defined default connection. This could be stored in a static property, but that seems kind of redundant.