How to manage dependency autoloading

徘徊边缘 提交于 2019-12-06 06:02:09

问题


When building a library I always provide an Autoloader class that handles autoloading for the library. The autoloader is registered like this:

require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();

I'm not sure though how to handle it if my library depends on another library. Imagine that PHPParser depends on a PHPLexer. Now when using the library one would need to write:

require_once 'path/to/PHP-Lexer/lib/PHPLexer/Autoloader.php';
PHPLexer_Autoloader::register();

require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();

If there are more than just one dependency or the dependencies have dependencies themselves, this can get messy quickly.

So how should one handle dependency autoloading?

One idea I had was that the library should handle autoloading for it's dependencies too, but that just doesn't feel right. Another idea would be to not provide an autoloader at all and assume that people use the UniversalClassLoader. That though doesn't seem right either.


回答1:


Well, there are a few ways to solve this problem, each with their own pros and cons:

  1. Use a common PSR-0 autoloader for all the libraries, and just register the location of the other project when initializing it.

    • Advantages:
      1. Very simple to implement
      2. Uses same code, so only one autoloader to use
      3. You can register all the paths in your application bootstrap file, so all library autoloading is defined in one place
    • Disadvantages
      1. Requires all libraries to implement a PSR-0 compatible file structure
      2. Leaks the abstraction level a bit since the application bootstrap needs to bootstrap everything inside the application including each individual library.
      3. Tightly couples the library's file structure to your autoloader (if a library implements a new file that conflicts, it'll break your autoloader even though theirs works file)
  2. Define a custom autoloader for each library.

    • Advantages
      1. Very simple to implement.
      2. Keeps library autoloading semantics in the library.
      3. Better maintainable code due to separation of responsibility
    • Disadvantages
      1. Lots of hard-coded classes in your bootstrap file (not a big deal though)
      2. Performance since an autoloaded class must go through multiple autoloaders
      3. Leaks the abstraction level since a library may need more effort to bootstrap than just an autoload
  3. Implement a bootstrap.php for each library (preferably provided by the library)

    • Advantages
      1. Pretty simple to implement.
      2. Keeps library autoloading semantics in the library
      3. Better code due to separation of concerns
      4. Ability to define non-trivial library bootstrap code without clouding other parts of the application
    • Disadvantages
      1. Still require a require_once '/path/to/lib/dir/bootstrap.php'; to initialize
      2. Performance (for the same reason as the 2nd solution)
      3. Most 3pd libraries do not implement a bootstrap file, so you may have to maintain one.

Personally, I use the third option. An example is the bootstrap.php file in my CryptLib library. To initialize it, just call bootstrap. You could also use any PSR-0 autoloader and just not call bootstrap.php, and it will work just fine. But with the bootstrap option, if I added functionality which needed to register itself at startup, I could just add it to the bootstrap.php file and it would automatically be executed (rather than telling users that they will need to do "x, y, z" on startup)...

With respect to the universal class loader option that you mentioned (calling spl_autoload_register() with no arguments), I personally don't like that option. First of all, it lowercases the classname (which is in violation of PSR-0, and I don't like it. I have gotten used to case sensitive class -> path mapping, and actually prefer it that way now). Secondly, it always uses relative paths, so it will defeat most opcode caches. There are other issues, but those are the big ones...




回答2:


If classes in library named by PSR-0 convention, than it's possible to use one autoloader for all libraries. Otherwise, library should provide own autoloader.




回答3:


add to class constructor

public function __construct(){
$this->Register();
}

after that on page where you whant to make load create an object

$obj = new PHPParser_Autoloader();


来源:https://stackoverflow.com/questions/7362957/how-to-manage-dependency-autoloading

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!