在 PHP 项目中，存在哪些模式来存储、访问和组织帮助程序对象？[关闭]

class Application {
    protected static $_singletonFoo=NULL;

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

}

这就是我的做法。它按需创建对象：

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

这就是我做事的方式，它尊重 OOP 原则，它比你现在做的代码要少，而且对象只有在代码第一次需要它时才会创建。

注意：我所介绍的甚至不是真正的单例模式。通过将构造函数 （Foo：：__constructor（）） 定义为私有，单例将只允许自身的一个实例。它只是所有“应用程序”实例可用的“全局”变量。这就是为什么我认为它的使用是有效的，因为它不会忽视良好的 OOP 原则。当然，就像世界上的任何东西一样，这种“模式”也不应该被过度使用！

我已经看到它被用于许多PHP框架，其中包括Zend Framework和Yii。你应该使用一个框架。我不会告诉你是哪一个。

补遗对于那些担心 TDD 的人来说，你仍然可以编造一些连接来注入依赖关系。它可能看起来像这样：

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;
        }
}

有足够的改进空间。这只是一个PoC，发挥你的想象力。

为什么要这样做？大多数情况下，应用程序不会进行单元测试，而是实际运行，希望在生产环境中运行。PHP的优势在于它的速度。PHP 不是，也永远不会像 Java 那样成为“干净的 OOP 语言”。

在应用程序中，只有一个 Application 类，并且每个帮助程序最多只有一个实例（如上所述的延迟加载）。当然，单身人士是坏事，但话又说回来，前提是他们不遵守现实世界。在我的例子中，他们确实如此。

刻板印象的“规则”，如“单身人士是坏人”，是邪恶的根源，它们是懒惰的人，不愿意自己思考。

是的，我知道，从技术上讲，PHP 宣言很糟糕。然而，它是一种成功的语言，以它黑客的方式。

补遗

一种功能风格：

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();

我会避免 Flavius 建议的 Singleton 方法。避免这种方法的原因有很多。它违反了良好的 OOP 原则。谷歌测试博客有一些关于 Singleton 以及如何避免它的好文章：

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

选择

1. 服务提供商

   http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2. 依赖注入

   http://en.wikipedia.org/wiki/Dependency_injection

   和PHP解释：

   http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

这是一篇关于这些替代方案的好文章：

http://martinfowler.com/articles/injection.html

实现依赖注入 （DI）：

• 我相信你应该问构造函数中需要什么才能使对象发挥作用：new YourObject($dependencyA, $dependencyB);

• 您可以手动提供所需的对象（依赖项）（）。但你也可以使用 DI 框架（维基百科页面提供了 PHP DI 框架的链接）。$application = new Application(new MessageHandler()

  重要的是，你只传入你实际使用的东西（调用一个动作），而不是你简单地传递给其他对象，因为它们需要它。这是“鲍勃叔叔”（Robert Martin）最近发表的一篇帖子，讨论了手动DI与使用框架。

关于弗拉维乌斯的解决方案的更多想法。我不希望这篇文章是反帖子，但我认为重要的是要了解为什么依赖注入，至少对我来说，比全局更好。

尽管它不是“真正的”单例实现，但我仍然认为 Flavius 弄错了。全局状态很糟糕。请注意，此类解决方案还使用难以测试的静态方法。

我知道很多人都这样做，批准它并使用它。但是阅读 Misko Heverys 的博客文章（谷歌可测试性专家），重读它并慢慢消化他所说的内容确实改变了我对设计的看法。

如果希望能够测试应用程序，则需要采用不同的方法来设计应用程序。当你进行测试优先编程时，你会遇到这样的困难：“接下来，我想在这段代码中实现日志记录;让我们先编写一个记录基本消息的测试，然后提出一个测试，强制您编写和使用无法替换的全局记录器。

我仍然在为我从该博客中获得的所有信息而苦苦挣扎，而且实施起来并不总是那么容易，而且我有很多问题。但是在我理解了 Misko Hevery 在说什么之后，我无法回到我之前所做的事情（是的，全局状态和 Singletons（大 S））：-）

我喜欢依赖注入的概念：

“依赖注入是指组件通过其构造函数、方法或直接进入字段来赋予其依赖关系。（摘自Pico Container网站)"

Fabien Potencier 写了一系列关于依赖注入和使用它们的必要性的非常好的文章。他还提供了一个名为 Pimple 的漂亮而小的依赖注入容器，我非常喜欢使用它（更多信息在 github 上）。

如上所述，我不喜欢使用单例。关于为什么单例不是好设计的一个很好的总结可以在 Steve Yegge 的博客中找到。

如果要使对象全局可用，则注册表模式可能对您感兴趣。要获得灵感，请查看 Zend Registry。

注册表与单例问题也是如此。

PHP 中的对象会占用大量内存，正如您可能在单元测试中看到的那样。因此，理想的做法是尽快销毁不需要的对象，为其他进程节省内存。考虑到这一点，我发现每个对象都适合两种模具之一。

1）该对象可能有许多有用的方法，或者需要多次调用，在这种情况下，我实现了一个单例/注册表：

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

2） 对象仅在调用它的方法/函数的生命周期内存在，在这种情况下，简单的创建有利于防止挥之不去的对象引用使对象保持活动时间过长。

$object = new Class();

将临时对象存储在任何位置可能会导致内存泄漏，因为在脚本的其余部分将对象保留在内存中时，可能会忘记对它们的引用。

为什么不阅读精美的手册呢？

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

我会选择返回初始化对象的函数：

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

在测试环境中，您可以将其定义为返回模型。您甚至可以使用 debug_backtrace（） 检测内部谁调用了该函数并返回不同的对象。你可以在里面注册谁想要得到什么对象，以获得一些洞察力，你的程序中实际发生了什么。

最好的方法是为这些资源提供某种容器。实现此容器的一些最常见方法：

单身 人士

不建议这样做，因为它很难测试，并且意味着全局状态。（单张力炎）

注册表

消除单调炎，错误我也不推荐注册表，因为它也是一种单例。（难以单元测试）

遗产

可惜的是，PHP 中没有多重继承，所以这限制了所有链。

依赖注入

这是一个更好的方法，但是一个更大的话题。

传统的

最简单的方法是使用构造函数或 setter 注入（使用 setter 或在类构造函数中传递依赖对象）。

框架

你可以滚动自己的依赖注入器，或者使用一些依赖注入框架，例如。亚迪夫

应用程序资源

您可以在应用程序引导程序（充当容器）中初始化每个资源，并在访问引导程序对象的应用程序中的任何位置访问它们。

这是在 Zend Framework 1.x 中实现的方法

资源加载程序

一种静态对象，仅在需要时加载（创建）所需的资源。这是一个非常聪明的方法。您可能会看到它的实际效果，例如实现 Symfony 的依赖注入组件

注入到特定层

应用程序中的任何位置并不总是需要这些资源。有时您只需要它们，例如在控制器 （MV C） 中。然后，您可以仅在此处注入资源。

常见的方法是使用 docblock 注释来添加注入元数据。

请在此处查看我的方法：

如何在 Zend Framework 中使用依赖注入？- 堆栈溢出

最后，我想在这里添加一个关于非常重要的事情的注释 - 缓存。
通常，尽管您选择了哪种技术，但您都应该考虑如何缓存资源。缓存将是资源本身。

应用程序可能非常大，并且根据每个请求加载所有资源的成本非常高。有很多方法，包括这个 appserver-in-php - Google Code 上的项目托管。