PHP: Standards of class constructors preventing instantiation

Just a question on standards.

I've created a wrapper class for PHP session management, that helps automatically organize session data based on certain internal modules accessing it. It's designed as a singleton, using a getInstance() method to instan开发者_如何学Gotiate, since there will only be a single session at a given time. Also, this came as a benefit to me, as I am able to prevent instantiation of the session object in the (albeit probably limited) chance that session_start() fails. As for an example:

    public static function getInstance(){
        if(!self::$_instance || !session_id()){
            if(session_start()){
                self::$_instance = new self(session_id());
            }else{
                return;
            }

        }
        return self::$_instance;
    }

My question is; although the use of a gateway getInstance() method works naturally here for a few reasons, is it common/good practice to implement public static getInstance() or create() methods in classes to control object creation if the object is reliant on external conditions?

I just find myself sticking to a convention of providing getInstance() in the case of singletons, and create() in the case of multiple instance objects.

TL;DR: I keep using getInstance() and create() methods to control all object instantiation. Am I doing it wrong?

EDIT: Refining my question a bit; Aside from using getInstance() for singletons, is my constructor wrapping with create() methods serving less purpose and more leaning towards bad convention? Should I be throwing Exceptions from the true constructor, or continue returning false from a create()?

Singletons are generally considered "bad"; see this section here for a flame war on the topic.

That said, using factory methods or factory classes to create objects is generally considered good, so you're fine there :)

I personally use the symfony dependency injection component (can be installed in any project without using the symfony framework) to simplify dependency injection and avoid singletons where it seems appropriate.

I do still use some singletons, where it makes sense to me; loggers and factory objects, for example, seem to naturally be single to me, so I make them that way. The idea is that global functionality (e.g. a factory) is fine, but global state is bad, I believe.

With regards to your amended question on whether to throw an Exception or whether to return false from your create() call; it depends on whether your application can continue successfully without the created object if not. If, for example, you were creating a database connection that is necessary to create a page, then throw an Exception. If you're doing something less essential, return false and continue on your merry way :)

getInstance() is used ALL over the place in the Zend Framework, which is my goto for standards and conventions in code.

as for the create(), what about using the magic __construct method so that when you do new Blah() it calls the __construct method for that class?

You should user __construct method then using create method. As __construct is called by itself you can do initialization and other things in constructor . Another benefit is you can forget to call create() method and your object can be in inconsistent state