你可能在項目代碼里見過這樣的寫法：$this->{'methodName'}() 或者 $this->{$variable}()。這就是動態(tài)方法調(diào)用，在運行時才確定要調(diào)用哪個方法。

看起來很靈活對吧？但用多了你就會發(fā)現(xiàn)，這玩意兒會給代碼維護帶來不少麻煩。IDE 找不到引用、全局搜索搜不到、代碼可讀性還差。

本文就來聊聊動態(tài)方法調(diào)用的三大坑，以及更好的替代方案。 

什么是動態(tài)方法調(diào)用

正常情況下，我們調(diào)用方法都是這樣寫的：$this->methodName()。方法名是寫死的，一眼就能看出來。

但動態(tài)方法調(diào)用不一樣，它允許你用變量或表達式來決定調(diào)用哪個方法：

$methodName = 'doSomething';
$this->{$methodName}();  // 等同于 $this->doSomething()

這種寫法確實靈活，特別是在寫框架或庫的時候，運行時才知道要調(diào)用什么方法。但在普通業(yè)務(wù)代碼里，這種靈活性往往會帶來更多問題。

舉個實際的例子。假設(shè)你在做一個 webhook 處理類，根據(jù)不同的事件類型調(diào)用不同的處理方法。比如收到 success 事件就調(diào)用 handleSuccessWebhook，收到 failure 事件就調(diào)用 handleFailureWebhook。

webhook 的數(shù)據(jù)結(jié)構(gòu)大概是這樣：

$payload = [
    'event' => 'success',
    'details' => [
        // ...
    ],
];

用動態(tài)方法調(diào)用的話，代碼可能是這樣：

final readonly class WebhookHandler
{
    public function handleWebhook(array $payload): void
    {
        $this->{'handle' . ucfirst($payload['event']) . 'Webhook'}($payload);
    }
 
    private function handleSuccessWebhook(array $payload): void
    {
        // 處理成功事件
    }
 
    private function handleFailureWebhook(array $payload): void
    {
        // 處理失敗事件
    }
 
    // 其他處理方法...
}

看到 handleWebhook 方法里那一長串了嗎？它從 $payload['event'] 取值，首字母大寫，拼上 handle 前綴和 Webhook 后綴，最后動態(tài)調(diào)用這個方法。

看起來挺聰明的，一行代碼搞定所有事件類型。但問題也就藏在這里。

動態(tài)方法調(diào)用的危險性

現(xiàn)在讓我們探討使用這種方法的一些危險性。

IDE 難以識別

我在動態(tài)方法調(diào)用中遇到的最大問題之一是集成開發(fā)環(huán)境(IDE),如 PhpStorm,很難理解它們的使用。由于方法名是在運行時構(gòu)造的,IDE 很難檢測 handleSuccessWebhook 和 handleFailureWebhook 方法是否真的被使用。這可能導(dǎo)致 IDE 將它們標(biāo)記為未使用,這可能會產(chǎn)生誤導(dǎo)。

過去,我曾被誘惑刪除 IDE 標(biāo)記為未使用的方法,后來才發(fā)現(xiàn)它們確實通過動態(tài)方法調(diào)用被使用了。這可能導(dǎo)致應(yīng)用程序中的錯誤和意外行為。幸運的是,我在部署到生產(chǎn)環(huán)境之前及時發(fā)現(xiàn)了它們。但那是一次險情。

PhpStorm 無法理解動態(tài)方法調(diào)用的另一個缺點是你無法充分利用 IDE 的重構(gòu)工具。例如,如果你想在 PhpStorm 中重命名一個方法,它將無法找到所有引用(因為它們是動態(tài)的),也不會為你重命名它們。如果你不小心,這可能導(dǎo)致代碼損壞。

更難查找

我發(fā)現(xiàn)動態(tài)方法調(diào)用的另一個問題是你無法輕松地在代碼庫中搜索它們的使用。

假設(shè)你想找到 handleSuccessWebhook 方法被調(diào)用的任何地方。所以你在 PhpStorm 中按 CMD+SHIFT+F 打開全局搜索窗口并搜索 "handleSuccessWebhook"。你不會找到任何結(jié)果(除了方法定義本身),因為方法名從未在代碼的其他地方明確提及。

此時,你必須問自己:"這個方法在任何地方被使用了嗎?還是可以安全刪除它?"如果你有一個全面的測試套件覆蓋了該特定方法并確認它正在被使用,那么這個問題就會變得更容易回答。但如果你的測試套件沒有覆蓋這個特定功能,那么你必須手動檢查代碼以查看它是否在任何地方被使用。這可能既耗時又容易出錯,尤其是在較大的代碼庫中。

更難閱讀

我個人發(fā)現(xiàn)動態(tài)方法調(diào)用會使代碼在第一眼看上去更難閱讀。你覺得這兩個中哪一個在第一眼看上去更清晰?

// 動態(tài)方法調(diào)用:
$this->{'handle' . ucfirst($payload['event']) . 'Webhook'}($payload);
 
// 或者,傳統(tǒng)方法調(diào)用:
$this->handleSuccessWebhook($payload);

我猜測大多數(shù)人會發(fā)現(xiàn)傳統(tǒng)方法調(diào)用更清晰。對于動態(tài)方法調(diào)用,你必須在心里解析字符串連接才能弄清楚正在調(diào)用什么方法。如果字符串連接更復(fù)雜,或者你不知道 $event 的可能值是什么,這可能特別具有挑戰(zhàn)性。

替代方法

出于上述原因,我通常在代碼中避免使用動態(tài)方法調(diào)用。相反,我更喜歡使用更明確的方法。

不過,這純粹是我的個人偏好,并不是說動態(tài)方法調(diào)用本質(zhì)上是不好的。所以如果你正在閱讀這篇文章并在自己的代碼中使用它們,請不要認為我在侮辱你的代碼。如果它適合你的用例,完全被測試覆蓋,并讓你保持高效,那么我完全支持。

我只是更喜歡使用更明確的方法所帶來的額外信心和安全性。而且我也認為它使代碼更容易閱讀,特別是對于剛接觸代碼庫的開發(fā)人員。

如果我要重構(gòu)上面的 WebhookHandler 類,我可能會使用 match 表達式:

final readonly class WebhookHandler
{
    public function handleWebhook(array $payload): void
    {
        match ($payload['event']) {
            'success' => $this->handleSuccessWebhook($payload),
            'failure' => $this->handleFailureWebhook($payload),
            default => throw new Exception('沒有該事件的處理器: ' . $event)
        };
    }
 
    private function handleSuccessWebhook(array $payload): void
    {
        // 在這里處理 "success" webhook...
    }
 
    private function handleFailureWebhook(array $payload): void
    {
        // 在這里處理 "failure" webhook...
    }
 
    // 其他 webhook 處理方法...
}

在上面的方法中,我們使用了 "match 表達式"來讀取負載的 event 字段,然后根據(jù)其值調(diào)用相應(yīng)的方法。如果事件不被識別,它會拋出一個異常。

通過使用這種方法,我們能夠在代碼中明確寫出方法名。因此,這意味著我們的 IDE 可以理解它們的使用,所以我們可以充分利用其功能(例如重構(gòu)工具,以及知道將返回哪些類型)。這也意味著我們可以輕松地在代碼庫中搜索它們的使用。我還認為,它使代碼在第一眼看上去更容易閱讀。

結(jié)論

希望本文讓你對在 PHP 中使用動態(tài)方法調(diào)用的危險性有所思考。雖然它們在某些場景中可能很有用,但它們也伴隨著一些你應(yīng)該注意的風(fēng)險。

到此這篇關(guān)于PHP中動態(tài)方法調(diào)用的三個避坑指南的文章就介紹到這了,更多相關(guān)PHP動態(tài)方法調(diào)用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論