In a PHP project, what patterns exist to store, ac

class Application {
    protected static $_singletonFoo=NULL;

    public static function foo() {
        if(NULL === self::$_singletonFoo) {
            self::$_singletonFoo = new Foo;
        }
        return self::$_singletonFoo;
    }

}

This is the way I'd do it. It creates the object on demand:

Application::foo()->bar();

It's the way I am doing it, it respects OOP principles, it's less code than how you're doing it right now,and the object is created only when the code needs it for the first time.

Note: what I've presented is not even a real singleton pattern. A singleton would allow only one instance of itself by defining the constructor (Foo::__constructor()) as private. It is only a "global" variable available to all "Application" instances. That's why I think its use is valid as it does NOT disregard good OOP principles. Of course, as anything in the world, this "pattern" should not be overused either!

I've seen this being used in many PHP frameworks, Zend Framework and Yii among them. And you should use a framework. I'm not going to tell you which one.

Addendum For the ones among you worrying about TDD, you can still make up some wiring to dependency-inject it. It could look like this:

class Application {
        protected static $_singletonFoo=NULL;
        protected static $_helperName = 'Foo';

        public static function setDefaultHelperName($helperName='Foo') {
                if(is_string($helperName)) {
                        self::$_helperName = $helperName;
                }
                elseif(is_object($helperName)) {
                        self::$_singletonFoo = $helperName;
                }
                else {
                        return FALSE;
                }
                return TRUE;
        }
        public static function foo() {
                if(NULL === self::$_singletonFoo) {
                        self::$_singletonFoo = new self::$_helperName;
                }
                return self::$_singletonFoo;
        }
}

There's enough room for improvement. It's just a PoC, use your imagination.

Why do it like that? Well, most of the time the application won't be unit-tested, it will actually be run, hopefully in a production environment. The strength of PHP is its speed. PHP is NOT and never will be a "clean OOP language", like Java.

Within an application, there is only one Application class and only one instance of each of its helpers, at most (as per lazy loading as above). Sure, singletons are bad, but then again, only if they don't adhere to the real world. In my example, they do.

Stereotyped "rules" like "singletons are bad" are the source of evil, they're for lazy people not willing to think for themselves.

Yeah, I know, the PHP manifesto is BAD, technically speaking. Yet it's a successful language, in its hackish way.

Addendum

One function style:

function app($class) {
    static $refs = array();

    //> Dependency injection in case of unit test
    if (is_object($class)) {
        $refs[get_class($class)] = $class;
        $class = get_class($class);
    }

    if (!isset($refs[$class]))
        $refs[$class] = new $class();

    return $refs[$class];
}

//> usage: app('Logger')->doWhatever();

回答3:

I like the concept of Dependency Injection:

"Dependency Injection is where components are given their dependencies through their constructors, methods, or directly into fields. (From Pico Container Website)"

Fabien Potencier wrote a really nice series of articles about Dependency Injection and the need to use them. He also offers a nice and small Dependency Injection Container named Pimple which I really much like to use (more info on github).

As stated above, I don't like the use of Singletons. A good summary on why Singletons aren't good design can be found here in Steve Yegge's blog.

回答4:

The best approach is to have some kind of a container for those resources. Some of the most common ways to implement this container:

Singleton

Not recommended because it is hard to test and implies a global state. (Singletonitis)

Registry

Eliminates singletonitis, bug I'd not recommend registry too, because it is a kind of singleton too. (Hard to unit test)

Inheritance

Pity, there is no multiple inheritance in PHP, so this limits all to the chain.

Dependency injection

This is a better approach, but a bigger topic.

Traditional

The simplest way of doing this is using constructor or setter injection (pass dependency object using setter or in the class constructor).

Frameworks

You may roll your own dependency injector, or using some of the dependency injection frameworks, eg. Yadif

Application resource

You may initialize each of your resources in the application bootstrap (which acts as a container), and access them anywhere in app accessing the bootstrap object.

This is the approach implemented in Zend Framework 1.x

Resource loader

A kind of a static object which loads (creates) needed resource only when needed. This is a very smart approach. You may see it in action e.g. implementing Symfony's Dependency Injection component

Injection to specific layer

The resources are not always needed anywhere in the application. Sometimes you just need them e.g. in the controllers (MV C ). Then you may inject the resources only there.

The common approach to this is using docblock comments to add injection metadata.

See my approach to this here:

How to use dependency injection in Zend Framework? - Stack Overflow

In the end, I'd like to add a note about very important thing here - caching.
In general, despite the technique you choose, you should think how the resources will be cached. The cache will be the resource itself.

The applications can be very big, and loading all resources upon each request is very expensive. There are many approaches, including this appserver-in-php - Project Hosting on Google Code.

回答5:

If you want to make objects globally available, the registry pattern could be interesting for you. For inspiration, have a look at Zend Registry.

So also the Registry vs. Singleton question.

回答6:

Objects in PHP take up a good amount of memory, as you have probably seen from your unit tests. Therefore it is ideal to destroy un-needed objects as soon as possible to save memory for other processes. With that in mind I find that every object fits one of two molds.

1) The object might has many useful methods or needs to be called more than once in which case I implement a singleton/registry:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) The object only exists for the life of the method/function calling it in which case a simple creation is beneficial to prevent lingering object references from keeping objects alive too long.

$object = new Class();

Storing temporary objects ANYWHERE might lead to memory leaks because references to them might be forgotten about keeping the object in memory for the rest of the script.

回答7:

I'd go for function returning initialized objects:

A('Users')->getCurrentUser();

In testing environment you can define it to return mock-ups. You can even detect inside who calls the function using debug_backtrace() and return different objects. You can register inside it who wants to get what objects to get some insights what's actually going on inside your program.

回答8:

Why not read the fine manual?

http://php.net/manual/en/language.oop5.autoload.php