11

考虑以下代码：

abstract class ExampleClass
{
    public static function regularStaticFunction()
    {
        return static::abstractStaticFunction();
    }

    abstract protected static function abstractStaticFunction();
}

ExampleClass::regularStaticFunction();

PhpStorm IDE 在声明中发出警告abstractStaticFunction，内容如下：

PHP 严格标准：静态函数“abstractStaticFunction”不应该是抽象的。

静态函数不应该是抽象的。

但是，PHP 在解析此类时会继续执行程序并输出以下内容：

PHP 严格标准：静态函数 ExampleClass::abstractStaticFunction() 在第 7 行的 php shell 代码中不应该是抽象的

在我看来，因为 PHP 允许在抽象类上调用静态函数，所以在抽象类上定义抽象静态函数应该是不可能的。

为什么解释器在 PHP 中允许抽象静态函数，当它们是荒谬的？

4

2 回答 2

32

这是Mark Amery回答的很好的解释：

PHP 错误报告 53081，要求删除警告，因为添加 static::foo()构造使抽象静态方法变得合理和有用。Rasmus Lerdorf（PHP 的创建者）首先将请求标记为虚假，然后通过一长串错误的推理来试图证明警告的合理性。然后，最后，发生了这种交换：

乔治奥

我知道但是：

abstract class cA
{
      //static function A(){self::B();} error, undefined method
      static function A(){static::B();} // good
      abstract static function B();
}

class cB extends cA
{
    static function B(){echo "ok";}
}

cB::A();

拉斯穆斯

对，这正是它应该如何工作的。

乔治奥

但这是不允许的:(

拉斯穆斯

什么是不允许的？

abstract class cA {
      static function A(){static::B();}
      abstract static function B();
}

class cB extends cA {
    static function B(){echo "ok";}
}

cB::A();

这工作正常。你显然不能调用 self::B()，但是 static::B() 很好。

Rasmus 声称他的示例中的代码“工作正常”是错误的；如您所知，它会引发严格模式警告。我猜他是在没有打开严格模式的情况下进行测试。无论如何，困惑的拉斯穆斯将请求错误地关闭为“虚假”。

这就是为什么警告仍然在语言中的原因。这可能不是一个完全令人满意的解释——你可能来到这里希望警告有合理的理由。不幸的是，在现实世界中，有时选择来自平凡的错误和糟糕的推理，而不是来自理性的决策。这只是其中之一。

幸运的是，作为PHP RFC: Reclassify E_STRICT notices的一部分，可敬的 Nikita Popov 已经从 PHP 7 中的语言中删除了警告。最终，理智占了上风，一旦 PHP 7 发布，我们都可以愉快地使用abstract static，而不会收到这个愚蠢的警告。

于 2017-01-12T11:18:49.177 回答
9

抽象静态函数并非没有意义！事实上，在我看来，它们使一些设计比我在没有它们的语言（如 Java 或 C#）中不得不求助的更简单、更清晰。

让我们举个例子。假设我正在编写某种普通的企业业务应用程序，它需要在两个 API 之间同步一些业务对象。这些 API 具有可以相互映射的对象模型，但使用不同的名称和不同的序列化格式。

在 PHP 中，多亏了抽象静态方法，我可以为这些业务对象类型定义一个抽象基类，看起来像这样......

abstract class ApiObject {
    /** The REST resource URL for this object type in the Foo API. */
    abstract static function fooApiResourceUrl();

    /** The REST resource URL for this object type in the Bar API. */
    abstract static function barApiResourceUrl();

    /** Given an XML response from the Foo API representing an object of this
        type, construct an instance. */
    abstract static function fromFooXml($xml);

    /** Given a JSON response from the Bar API representing an object of this
        type, construct an instance. */
    abstract static function fromBarJson($json);

    /** Serialize this object in the XML format that the Foo API understands */
    abstract function toFooXml();

    /** Serialize this object as JSON that the Bar API understands */
    abstract function toBarJson();
}

...然后我创建的每个具体子类都将保证提供从两个 API 中的任何一个获取它并反序列化它所需的所有信息，或者对其进行序列化并将其发送到任一 API。然后，稍后，我可以编写一些这样的代码：

// Ensure that all instances of these types that exist in the Foo API also
// exist in the Bar API:
$classesToSync = ['Widget', 'Frobnicator', 'Lead', 'Invoice'];
foreach ($classesToSync as $apiObjectClass) {
    $fooObjXmls = httpGetRequest($apiObjectClass::fooApiResourceUrl());
    foreach ($fooObjXmls as $fooObjXml) {
        $fooObj = $apiObjectClass::fromFooXml($fooObjXml);
        $json = $fooObj->toBarJson();
        httpPutRequest($apiObjectClass::barApiResourceUrl(), $json);
    }
}

我是否严格需要抽象静态方法来编写上面的程序？不; 我还可以使用其他模式，例如让每个模型类与相应的工厂类配对，该工厂类负责从其 JSON 或 XML 表示中实例化它。但是这样的设计比我上面展示的更复杂。

那么，为什么它们被允许的答案很简单，就是它们很有用，因为它们启用了一些没有它们就不可能实现的漂亮、简单的模式。当然，也存在反对它们的论点，其中一个在问题中给出 - 鉴于抽象类上的静态方法是可调用的，在类上公开抽象静态方法是丑陋的。我不觉得这样的考虑特别有说服力，但即使你这样做了，它们与抽象静态方法提供的实用程序之间仍然存在权衡，PHP 维护人员可能已经权衡了它们并选择了让抽象静态方法的一面存在。

于 2018-12-08T15:03:06.993 回答