Why should we use composer rather than using include_once or require_once?

假装没事ソ 提交于 2020-04-15 16:10:30

问题


I have searched many blogs and websites but I didn't find any perfect answer. whenever I use composer I have to include the autoload.php file and then for each class to autoload I have to use that class with the namespace.now I want to know what is the advantage of this composer where I can easily include the class file by include_once or require_once rather than using both autoload.php and the class file individually. when I use composer I have to write these code:

include_once("vendor/autoload.php");
use namespace/derectoryname/classname;

whenever I include manually than

include_once("classname.php");

can anyone clear these?


回答1:


First and foremost, composer main advantage is to handle dependencies (and your dependencies' dependencies, and so on). The autoloader is just frosting on the cake.

The question would be better posed as include vs autoloader, and then it gets slightly more interesting.

First, brevity. With one approach you'll end up using two declarations per file: use and include, whereas using the autoloader you'll just need to declare the use statements, and let the autoloader do the dirty work of actually loading the file.

Also, performance. If you include or require your requirement at the top of your file, you will always load that other file. With the autoloader, you'll only do so if you actually try to use the required class. Until you try to instantiate or use any of the required classes, the autoloader wont hit the filesystem and try to find the required class, making it more efficient, and only doing the work when you actually need the work.

As a somewhat crude example:

use Namespace\Package\Service\ServiceProvider
use Namespace\Package\Exception\ServiceProviderException

if (isset($options['service_id'])) {
   try {
      $service = ServiceProvider::getService($options['service_id']);
   }
   catch (ServiceProviderException $e) {
       // do your exception handling
   }
}
else {
   // and now for something entirely different
}

With this, the file that declares ServiceProvider is only going to get loaded if you actually meet the requirements, and the file that declares ServiceProviderException only when if you have to catch the exception (although to be fair it would have been included by the autoloader when ServiceProvider needed to throw that exception, and not before).

On top of that, you've got a neater separation of concerns. Your ClassA that needs to use NameSpace\Package\ClassB is not required to know where you are actually storing that file. It's not its job, and shouldn't care about the actual structure of the filesystem, making the code more portable. Someone somewhere else might have a different vendor structure than you and still get use your code easily if it uses an autoloader, instead of hardcoding file paths in your require statements.

This should be more or less enough to show you that autoloading is a much more modern, efficient, and portable way to work than including your requirements manually.

And since you are already using composer to handle your dependencies, which is awesome, you get the autoloader benefits for free!



来源:https://stackoverflow.com/questions/41660336/why-should-we-use-composer-rather-than-using-include-once-or-require-once

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