文件加载---理解一个project的第一步
当我最开始写php的时候，总是担心这个问题：我在这儿new的一个class能加载到对应的类文件吗？毕竟一运行就报fatal error，什么**文件没找到，类无法实例化等等是一种很“低级”的错误，怕别人看了笑话。于是每接一个新任务，我总想把它的加载过程弄清楚（以前只知道几个html标签和样式，不知算不算web开发），有时头儿看了说还有闲心看这个，赶紧写逻辑，照这样做就行了......你妹你知道当然有把握了d:，后来发现原来流程都差不多。
在一个ide中开发时，如c++/java，一般是新建一个工程，通过ide新添加一个文件到指定目录下，然后#include/import进来即可，php则使这一步骤更加过程化，文件的加载过程基本确定了这个project（框架或者自搭的项目）的目录结构和文件的分门别类。
不管框架还是自搭的项目总得有个入口文件，这时要事先加载一些基本信息，如配置文件、通用方法等，使用的基本是手动直接加载单个文件形式，使用下面四个方法之一：
include、require、include_once、require_once
include('config.php'); require('database.php');
涉及到类文件的加载，少部分是直接加载，比如，通用方法作为静态方法写在一个类utilities中，因为是后边很多要用到的方法（如错误输出、curl请求、随机字符串生成...），所以用类封装起来，一般也是在加载配置文件时连带加载进来
include('utilities.php');
而更通用的情况是：类的动态加载。首先不谈的加载的方式，来看看大概什么时候会用到一个类和实例：
1. 最明显的，$obj = new a;  它的变种$classname = 'a'; $obj = $classname; 都一样；
2. 类的静态方法、静态变量和常量的调用，即utilities::httprequest()、utilities::$instance、utilities::host；
3. 在php函数中，使用了回调函数的情况，最典型的call_user_func_array()（call_user_func），还有其他用到了callback的地方，如数组中的array_walk、array_map，它们需要一个回调函数作为参数。
回调函数非常灵活，不止可以是简单函数，还可以是对象的方法，包括静态类方法。因为可以用对象方法或静态方法，所以这钟时候也要去加载对应的类文件。自php5.3起，回调函数还可以像js中，用匿名函数来实现。
class a{ public static function cube($var){ return pow($var, 3); } public function twice($var){ return 2*$var; } } // 使用类的静态方法 $num = call_user_func('a::cube', 5); // 使用对象 $obj = new a; $num = call_user_func_array(array($obj, 'twice'), array(7));
严格来说上例中的call_user_func_array在之前已经实例化了对象，但是存在这么个用法，它完全也可以使用类静态方法。
首先要明白的是，为什么需要动态加载。php是脚本语言，我们访问时，是以脚本为可用资源，比如现在根目录有个index.php文件，它没有include任何其他文件，当我们直接以localhost/index.php来访问时，可以访问到index.php中的全部资源，如果index.php中定义了一个普通类a，在该脚本中实例化一个a的对象时，程序会这样反应：哦，我已经看到了a的定义，可以直接实例化它（不需要加载其他文件）。如果还有类b、c、d等很多类，全部写在index.php中显然不行，那就写在其他文件中，再include进来（include已经在做加载的工作了），这样对程序来说，也是“可见”的了。
但是随着系统功能的增多，类越来越多，各个类的功能也不同，有的直接定义数据库的操作，读取数据库的数据，有的是控制访问脚本时要运行的方法，有的则是将要展现出来的页面，有的是我们引用的第三方核心库，于是，当我们把所有的文件放在一个目录中时，虽然可以直接include加载，但这些文件摆放显得既杂乱无章又难找，维护成本还高。好呗，那就在根目录下再分别建几个目录，目录a专门存放与数据库打交道的脚本，目录b是系统的各种配置信息文件，目录c是控制我们进入程序时的入口控制方法的脚本，目录d是即将展示到浏览器的页面......
于是mvc架构慢慢就演化出来了，我们不能再像以前那样直接include，脚本都放在特定的目录下，如controller目录下存放的是各种控制器，加载控制器时，我们得这样include('root/controller/indexcontroller.php')，每次都在文件前面弄一大串的include不仅看着头疼，简直让人累觉不爱。既然有了获取当前文件路径和类名的现成方法，为何不将类名与文件名对应起来，而只要是控制器类的脚本就全放在根目录的controller子目录下边，就可以写一个方法，只要是控制器类，在这个方法中运行include(root.'controller/'.$classname.'.php');这一句，root为根目录常量，$classname为传入的类名，只要是模型类，就这样include(root.'model/'.$classname.'.php');，全凭这个函数来动态控制到哪个目录里边去找，这个project可能就是这样的：
无形中，就建立起了类名和文件名的对应规则，文件和所在的目录的对应规则，该project下有哪些这样的目录和文件呢？啊原来是放控制器的controller、放配置信息的config等等，再次于无形中得知了这个project的结构，而上面说的，利用函数根据一定条件（传入参数）可知自动到哪个目录下去加载该文件，而不是一个个写死的include，就是所谓的文件的动态加载了。
因此，当你要新建一个**类文件时，也就知道，哦在这个project中，我应该放在这个目录下，文件的命名应该与类名相同，这样就一定能加载到了~~~接下来就是写业务逻辑的一个“愉快的过程”。
知道什么时候会动态加载及为什么要动态加载后，接下来就是来实现了，也就是上面说到的利用函数来加载某个文件，就是要写好这个“函数”来实现这个过程。常用的有三种方式：
1. __autoload
我第一次学的时候就是用的就是这个，魔术函数，只要定义了php程序就会在要用到一个类时自动调用它进行文件动态加载，一样，既然它是个函数，就要让程序对__autoload的定义可见，不然从哪儿调用它呢？一般来说，作为后边程序大部分地方要用到的方法，我们都会放在一个单独的文件中，在程序的入口处加载进来，一个project总得有几个文件是手动include的，完全可以在开头单独include进来，或者放在配置信息中，加载配置信息时就加载进来了。它的原型：
void __autoload ( string $class )
参数当前加载的类名名称（注意如果有命名空间，则包含命名空间前缀），下面是一个针对上面的图片结构的简单示例：
// file: autoload.php // root为已经定义的根目录常量 function __autoload($classname){ try{ if(file_exists(root.'controller/'.$classname.'.php')){// 检查controller include(root.'controller/'.$classname.'.php'); } else if(file_exists(root.'model/'.$classname.'.php')){// 检查model include(root.'model/'.$classname.'.php'); } else if(file_exists(root.'lib/'.$classname.'.php')){// 检查lib include(root.'lib/'.$classname.'.php'); } else{ // 找不到该文件 throw new exception(error: can't find file {$classname}.php); } } catch(exception $e){ echo $e.getmessage(); exit; } }
2. spl_autoload_register
__autoload实际上也差不多了，但它是php定义的，如果现在有个东西写了并调用之后，就告诉程序说，我不用__autoload来加载文件了，我已经定义了一个专门加载文件的方法（比如名称是loadclass），以后需要加载一个类文件时，你就用它吧。spl_autoload_register就是这样一个能告诉程序这样去做的方法，而且自定义加载方法将会更灵活，可以指定多个加载函数，spl_autoload_register函数会将这些函数放在一个队列中，并激活它们，在调用时逐个激活：“if there must be multiple autoload functions, spl_autoload_register() allows for this. it effectively creates a queue of autoload functions, and runs through each of them in the order they are defined. ”，php.net上（http://php.net/manual/en/function.spl-autoload-register.php）也确实如此解释，spl_autoload_unregister则是从加载函数队列中注销。
另外spl_autoload_functions()函数，可以获取我们注册了哪些函数；spl_autoload_call($class)函数，尝试调用所有已注册的加载函数来加载$class的类文件。
对于spl_autoload_register的解释，我的理解是，如果用spl_autoload_register注册了n个函数在加载队列中，因为它自动激活它们嘛，现在我要实例化一个类，在第1个加载函数中加载失败了，然后尝试第2个函数，第二个失败则尝试第3个，'''，直到第n个函数走完，若还没加载成功，就报错，只要中间一个加载成功就成功了，but事实好像有点出入。
还是用上一个图片中的目录结构，
1、在controller目下创建indexcontroller.php文件，包含类indexcontroller；
2、在model目录下创建usermodel.php文件，包含类usermodel；
3、首页写个类加载脚本autoload.php，代码如下：
// file: autoload.php define('ds', directory_separator); define('root', rtrim(dirname(__file__), '/\\').ds); class autoload{ public static function autoloadregister($loadfunc = 'autoload::loadcontrollerclass', $enable = true){ return $enable ? spl_autoload_register($loadfunc) : spl_autoload_unregister($loadfunc); } // 加载控制器类 public static function loadcontrollerclass($classname){ if(file_exists(root.'controller'.ds.$classname.'.php')){// 检查controller include(root.'controller'.ds.$classname.'.php'); echo root.'controller'.ds.$classname.'.php'.'
'; } else{ echo error: can't find file {$classname}.php in .root.controller; exit; } } // 加载模型类 public static function loadmodelclass($classname){ if(file_exists(root.'model'.ds.$classname.'.php')){// 检查model include(root.'model'.ds.$classname.'.php'); echo root.'model'.ds.$classname.'.php'.'
'; } else{ echo error: can't find file {$classname}.php in .root.model; exit; } } }
4、测试脚本，测试类是否能加载
// 注册两个加载函数 autoload::autoloadregister('autoload::loadcontrollerclass'); autoload::autoloadregister('autoload::loadmodelclass'); // 查看总共注册了哪些加载函数 echo 'register functions=> '; print_r(spl_autoload_functions()); // 分别实例化一个controller类和model类 $indexcon = new indexcontroller; $usermod = new usermodel;
结果是这样
这不科学啊，spl_autoload_functions数组显示两个函数都注册了，但是当实例化usermodel类时它还是跑到controller目录中去找，两个类的实例化调用的自动加载方法都是autoload::loadcontrollerclass，所以usermodel类文件加载报错......注意到spl_autoload_register方法的第三个参数， 是添加一个加载函数时放在栈中的位置，于是我另写一个类似的类otherload，只是为了将loadmodelclass方法放到队列首部：
class otherload{ public static function autoloadregister($loadfunc = 'otherload::loadmodelclass', $enable = true){ // 默认将loadmodelclass放在队首 return $enable ? spl_autoload_register($loadfunc, true, true) : spl_autoload_unregister($loadfunc); } // 加载模型类 public static function loadmodelclass($classname){ if(file_exists(root.'model'.ds.$classname.'.php')){// 检查model include(root.'model'.ds.$classname.'.php'); echo root.'model'.ds.$classname.'.php'.'
'; } else{ echo error: can't find file {$classname}.php in .root.model; exit; } } }
测试是这样
// 注册三个加载函数 autoload::autoloadregister('autoload::loadcontrollerclass'); autoload::autoloadregister('autoload::loadmodelclass'); otherload::autoloadregister('otherload::loadmodelclass'); // 查看总共注册了哪些加载函数 echo 'register functions=> '; print_r(spl_autoload_functions()); // 分别实例化一个controller类和model类 $indexcon = new indexcontroller; $usermod = new usermodel;
这次的结果是这样：
可以看到，这次是在加载indexcontroller类时不成功，因为它只调用了loadmodelclass方法，再看看spl_autoload_functions返回的数组，otherload类的loadmodelclass方法在最前面，难道说，只有在加载函数队列最前面的函数才被用于自动加载，其他无效？这是什么状况？
使用spl_autoload_call('indexcontroller')来“尝试调用所有已注册的函数来装载请求类”，还是报这个错。
翻了下别人的文章，包括github上的博客，也就是列举了下手册上说的“可以一次注册多个加载函数 bala bala......”，难道没有人试过，还是我的理解有问题>3关于spl_autoload_register还有几个有意思的地方：
1、 一个函数只会加载到函数队列中一次，重复加载也是如此；
2、 spl_autoload_register如果不指定加载函数（第一个参数），则默认使用加载函数spl_autoload（功能类似于__autoload，是它的默认实现形式）
3、 spl_autoload_register指定了__autoload为加载函数，则一定要实现__autoload;
4、 同时实现了spl_autoload_register和__autoload，优先使用spl_autoload_register注册的加载函数。
以上几种情况几乎都可从php.net的note中找到测试例子，老外写得挺有意思，可供参考。上面第2点还需要注意，比如现在在根目录创建一个目录，使用默认函数来加载：
// 设置加载文件的扩展名，将只加载*.php的文件 spl_autoload_extensions('.php'); // 默认使用spl_autoload加载文件，只能加载当前目录下文件：小写类名.php spl_autoload_register(); // 测试 // $obj = new a;
spl_autoload_extensions设置加载时只认哪些扩展类型的文件，默认是.php或者.inc文件，这里设置成.php，然后就是调用注册函数。在根目录下创建一个a.php文件，新建一个类a，加载成功，再将文件名改成a.php，照样加载成功。需要留意spl_autoload默认将类名转小写，但是a.php照样加载成功，因为windows的文件是大小写不敏感的（在同一目录下创建一个d.txt，再创建d.txt会认为是同一个文件），对于mac os x也是这样，但linux就是大小写敏感了，测试时要注意这点。
也不是全要自动加载，如ci，它将加载文件封装为一个核心类ci_loader，程序启动时先include必要的脚本（其他要用的核心类），然后再等需要使用时，ci_loader实例作为当前控制器类或模型类等的一个属性成员，通过调用它的方法来include各种model（模型）、view（视图）、database（数据库对象）、helper（辅助函数）等等。
无论用不用动态加载，必须保证的是，文件分门别类的放好，文件按一定规则命名，这是一个健壮、高扩展、高易用的project必备的，写起代码来也方便。当然加载文件的多少，占内存的多少，各有不同，也是评判一个框架的若干标准。弄清楚加载方式，熟悉一个框架结构不就是很容易的事了=_=...