【问题标题】:Autoloading functions best practices自动加载函数最佳实践
【发布时间】:2011-04-08 21:18:33
【问题描述】:

在使用带有 PHP 的 __autoload() 函数的 OOP 范例的 PHP 项目上工作时,以下哪项被认为是管理独立函数的最佳实践:

(为简洁起见,对所提供的示例进行了简化)

tl;dr:通常如何处理独立函数加载:

  • 伪自动加载(例如通过 __callStatic 魔术)[选项 1]
  • 抽象助手类分组静态方法 [选项 2]
  • 另一种选择

另外请注意,我已经发布了一个有关选项 1 的参数/引用问题的相关问题,可以在此处找到:__callStatic(), call_user_func_array(), references, and PHP 5.3.1

在index.php:

function __autoload($class){
    require $class . '.class.php';
}

选项1; “自动加载”功能的抽象 Core 类(或 Library 或其他):

## Core.class.php
abstract class Core{
    public static function __callStatic($function, $arguments){
        if(!function_exists($function)){
            require $function . '.function.php';
        }
        return call_user_func_array($function, $arguments);
    }
}

## SayHello.function.php
function sayHello(){
    echo 'Hello';
}

## SayGoodbye.function.php
function sayGoodbye(){
    echo 'Goodbye';
}

## index.php
Core::sayHello();   // Hello
Core::sayGoodbye(); // Goodbye

选项 2;将相关函数分组为抽象的“帮助”类以静态调用:

## SayStuff.class.php
abstract class SayStuff{
    public static function sayHello(){
        echo 'Hello';
    }
    public static function sayGoodbye(){
        echo 'Goodbye';
    }
}

## index.php
SayStuff::sayHello();   // Hello
SayStuff::sayGoodbye(); // Goodbye

【问题讨论】:

    标签: php function static-libraries autoload


    【解决方案1】:

    我在这里没有看到一个确切的问题,但由于标题包含“最佳实践”,因此这是我最近发现的一条建议:

    它seems to be preferable to use PHP's SPL autoload functions instead of __autoload()(“Dissection by David”博客上的一个很好的例子)。

    引用链接的博客文章:

    使用 SPL 的最大好处 版本(我迄今为止看到的)是:

    • 可以使用/注册多个函数 — 函数是 链接在一起并按顺序使用 直到一个功能 加载类文件。 + 函数也可以即时注销。
    • 可以实现一些不错的错误处理(请参阅 示例 3),虽然有些帽子 try/catch 所以这可能不适合你 编码风格。
    • 使用不同的扩展名(即不是 .php 或 .php.inc 或 .inc)如果 你这么选择 spl_autoload_extensions()
    • 确保“我的”自动加载类不被覆盖!如果 __autoload() 稍后运行,我的 spl_autoload_register()'ed 函数 不会被替换。

    【讨论】:

    • 除此之外,使用符合 PSR-0 的自动加载器可能是个好主意。有关详细信息,请参阅groups.google.com/group/php-standards/web/psr-0-final-proposal
    • 感谢 Frosty Z; 我很欣赏SPL 的建议,而不是非SPL 自动加载。我肯定会在未来的项目中开始实施它,以代替提供的核心 __autoload。我将在我的问题中添加一个 tl;dr 以进行总结。
    【解决方案2】:

    我不会使用“选项 1”,主要是因为它使用 call_user_func*,这会比直接调用函数慢。

    如果你只需要一些没有真正联系在一起的辅助函数,那么我可能会包含一个文件 helpers.php,它只会列出我所有的辅助函数,这些函数自封装以来没有封装在静态类中在这种情况下并没有真正取得任何成就。大多数情况下,每个请求都会使用辅助函数,因此在每个请求中包含此文件不会造成任何伤害...

    【讨论】:

    • 感谢 rATRIJS; 我也在考虑这些问题,这可能会严重影响递归函数。随着时间的推移,我编写了许多从本质上扩展 PHP 核心功能的函数,虽然有些可能会在给定项目中使用,但有些则不会。由于一些的普遍性,将它们划分为逻辑组(类)很困难,但这是我仍在考虑的一个选项。每次都将它们作为一个庞大的库加载并不是最佳的(我不认为),因为当我完成整合我的库时它会变得庞大。
    • 我注意到“选项 1”的另一个问题是带有通过引用传递的参数的函数,当然根本不起作用。忘记了那个警告。
    猜你喜欢
    • 2010-12-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-12-06
    • 2012-01-05
    • 2010-10-03
    • 2011-04-26
    相关资源
    最近更新 更多