php – 静态函数很糟糕 – 但是替代方案是什么？

在我的示例中,我使用的是PHP框架Yii2,但我认为这适用于大多数OO语言.

我有一个ActiveRecord基类,我的大多数业务对象都是从项目.

目前,如果我想要一个Project实例,我打电话

Project::findOne(['id' => $id]);

findOne是ActiveRecord的静态方法(它是Yii2框架的一部分).所以这是不好的形式,因为在编写单元测试时我不能轻易地模拟/存根这个调用的返回.

但是解决这个问题的最佳方法是什么？

我可以创建一个继承自ActiveRecord的类CActiveRecord,并将静态调用包装在非静态调用中并在任何地方使用 – 但是我必须实例化一个抛弃的Project对象才能获得实际的实例.如果Project对象需要一些繁重的配置来实例化 – 我会将随机的废话传递给构造函数只是为了得到一个实例.

摘要：
简单地将静态更改为非静态似乎是错误的 – 我不应该将函数移到其他地方吗？如果是的话,在哪里？

解决方法:

静态调用的问题是与特定其他代码段的硬耦合.只是在“动态”调用中包装它不会使这更好：

$c = new CProject;
$c->findOne(); // Calls Project::findOne()

这非常毫无意义.问题不是 – >的语法vs. ::,问题是这个特定的代码引用了一个特定的其他类,并且您不能轻易地将此类替换为其他类.您正在构建类/对象之间的刚性,硬编码依赖关系,这使得它们难以分开,这使得您的代码难以测试,并且这使得代码适应不同情况变得更加困难.

替代方案是依赖注入：

function foo(Project $project) {
    $p = $project->findOne();
}

此函数不与任何一个特定的Project类耦合,而是与仅提供类似于Project的接口的类耦合.事实上,Project甚至可以只是一个界面.在这里调用哪个特定的类和方法然后在某处完全不同,就像你的依赖注入容器一样;或者只是这段代码的调用者.

这使得将这些代码分开并以不同方式将其重新组合在一起变得更加容易,这对于手头的情况是必要的.这并不是说它不起作用,你根本不应该使用静态调用,但你真的需要知道你在每个硬编码的类名中建立的交叉依赖关系,以及这是否可能导致一个问题就行了.对于即使是中等复杂和/或不断增长的软件项目,它几乎肯定会以某种形式或最终导致摩擦.

有关更深入的文章,请参阅How Not To Kill Your Testability Using Statics.