5

所以，这就是交易。我设法在不使用全局变量或静态类/函数的情况下制作了一个框架。

我正在使用一种使用工厂的依赖注入形式。由于该框架将用于各种事情，因此我正在创建一个更通用的 Factory 来构建您的类，并递归地使用它的依赖项。

问题是，为了节省内存，每次实例化一个对象时，Factory 都会存储对它的引用，因此如果另一个对象依赖于该对象，则 Factory 只需返回该引用。这样我们就不需要两次实例化同一个对象。

这意味着，在许多类中，我们将对同一个对象有许多不同的引用。例如，如果我声明 Blog_model、Blog_controller、Blog_view、Form_validation 需要 Config 对象，它们中的每一个都将使用对同一 Config 对象的引用进行实例化，尽管是注入。

我不熟悉单元测试或任何类型的自动测试。我刚刚发现使用全局变量和静态变量是不好的（这就是我重写我使用的框架的原因）。我想问的是，这是否引入了全局状态？它是否会以任何方式阻碍测试？

- - 更新 - - -

它是一个用 PHP 编写的 MVC 框架。

4

2 回答 2

3

就我阅读这个问题而言，您实际上已经创建了一个仅支持单一生活方式的依赖注入容器。

与 DI 密切相关的是生命周期管理的概念。如果我们多次请求一个特定类型的实例，我们是每次都得到相同的引用，还是每次都得到一个新的实例？

如果我们每次将其称为Singleton 生活方式时都得到相同的实例- 不要与 Singleton 设计模式混淆。

如果我们每次都获得一个新实例，我们称它为Transient Lifestyle。

还有其他类型的生活方式，例如scoped、pooled等，但以上两种是最基本的生活方式。

在我看来，您的 DI 容器仅支持单例生活方式。这与 Global state 不同，但 state在容器的单个实例中共享。但是，如果你丢弃容器实例，你也会丢弃共享状态，所以它比全局状态更容易摆脱。

于 2011-04-08T10:59:38.347 回答
2

是的，它确实引入了全局状态，因为您的工厂返回对刚刚创建的对象的引用。

您没有说您使用的是哪种语言，但如果您使用的是 c++，您的工厂方法应该返回一个 shared_ptr（shared_ptr 的类型应该是您正在创建的对象的基类）。

于 2011-04-08T10:43:34.573 回答