我有一个简单的框架＆＃34;其主要实例是$ app。现在，实现自动加载器的最佳方法是什么（不使用Composer）。我需要的是有一个处理所有自动加载的类（支持各种命名空间）。我有一些方法/困境。
起初我以为我应该创建一个＆＃34;静态＆＃34;处理一切的类。但后来我想到了一些事情。如果我在实例化$ app（包含所有路径）之前使用自动加载器，我需要定义$ app之外的路径。而且，如果在自动加载类时出现错误，我将无法正确处理错误（错误处理程序在$ app中，并在之后实例化）。
然后我考虑了依赖注入，使自动加载器成为应用程序内的一个对象。这将解决错误处理问题，并且不需要我硬编码路径或使它们成为全局变量。但在我实例化自动加载器之前，我还必须加载许多类（包括$ app）。
但是，由于这个问题，我真的处在痛苦的世界里，我真的不知道从哪里开始，是否有一些我应该考虑的建议？你能解释一下我应该使用哪种方法以及为什么？
感谢。
答案 0 :(得分：2)
如果您编写框架，则应始终查看现有框架，这些框架已经正确地解决了您的问题。然后你会受到启发或只是使用该组件。一个很好的起点是symfony，它们的组件是分离和测试的。如果您使用composer加载它或手动下载它是您的选择;）
他们还有一个可以使用的Classloader http://symfony.com/doc/2.0/components/class_loader.html。或者你只是看看他们的方法是什么。
自动加载器（或您的类加载器）应该包含在应用程序的开头，这应该是您直接包含的唯一类。
如果你想加载你的课程动态，你必须看看你的课程如何存储，有不同的“标准”方式，如PSR0 http://www.php-fig.org/psr/psr-0/。如果您希望用户添加自己的类，那么当他们使用您的框架时，您应该考虑支持多种标准。
答案 1 :(得分：2)
由于我在这些问题中得到的提示，我搜索了一些，并从哪里学习找到了很好的资源。
自动加载基本上是程序找到未知类名并尝试加载它而不定义类名的过程。如果没有自动加载器，此行为将导致致命错误（至少对于PHP）。使用自动加载器，事情会发生变化，程序将尝试加载类名，但不知道在哪里找到它，但依赖于为此目的而考虑的函数或类，这些函数/类被称为自动加载器。 / p>
在PHP中，我们有两种不同的方法来实现自动加载（您可能会发现从PHP's site读取它很有用。）。第一个是旧的__autoload()，最新的是spl_autoload_register()。但究竟有什么区别？基本上__autoload（）是独一无二的，有多个自动加载器会给你带来很多麻烦，并会让你解决一个问题，这个问题可以通过使用最新的spl_autoload_ *函数轻松避免。另一方面， spl_autoload_register（）允许程序通过将它们放入堆栈中来拥有多个自动加载器，这样整个系统变得更加灵活，而且复杂得多（为了不同的目的而拥有一个Autoloader）在处理许多请求时具有很大的独特功能，这样你就可以减少代码的可维护性和可重用性。 警告：使用spl_autoload_register（）会覆盖__autoload（），所以要小心。
让我们首先说PSR-4更新，它被认为是PSR-0的改进，但不是必须的，你必须使用4而不是0，作为标准（PSR） -4）陈述：
它完全可互操作，除了包括PSR-0在内的任何其他自动加载规范外，还可以使用。
那我为什么要用一个而不是另一个？
现在由您决定，但作为建议PSR-4解决了＃34;嵌套＆＃34;问题PSR-0，所以你应该使用前者。假设我有一个应用程序，而我的应用程序依赖于外部组件，PSR-0遵循以下语法：
\vendor\(sub_namespaces\)class_name
可能缺少sub_namespaces。但这转化为硬盘驱动器上的完全限定路径：
path/to/project/vendor/sub/namespaces/class/name.php
现在假设我想在我的应用程序中包含一个名为YourLibrary的库
\YourDeveloper\YourLibrary\YourFunction
这将转化为
/path/to/project/YourDeveloper/YourLibrary/YourFunction
这就是问题所在，如果我想将该库放在我的子文件夹中该怎么办：
/path/to/project/vendor/vendor_name
PSR-0是绝对的，你不能只修改命名空间来控制这种行为（它会很愚蠢并需要太多时间）所以它会转化为：
/path/to/project/vendor/YourDeveloper/src/YourDeveloper/YourLibrary/YourFunction
是不是非常嵌套和冗余？好吧，使用PSR-4你可以避免这种情况并将其转换为
/path/to/project/vendor/YourDeveloper/YourLibrary/YourFunction
无需更改名称空间或自动加载器。这基本上就是PSR-4的工作原理。这个解释很简短，但它让你一眼就看出为什么PSR-4诞生了，为什么你应该使用它。如果您需要更充分的解释，可以阅读PSR-0/4规范，或者您可以在sitepoint上阅读this精美文章。
如果你已经在编程世界呆了足够的时间，你可能最终不会问这样的问题。但如果你是，你可能是一个新的程序员，或者你还没有成为一名程序员，这就是你应该阅读这个答案的原因。 在IT世界中，特别是在编程中，标准几乎就是一切。如果我们没有遵循标准，我们甚至可能在我们的计算机上没有视频。如果有人遵循他们自己的标准，一切都会看起来很乱，在这种情况下，Autoloaders会变得个性化;所以不是拥有一个SIMPLE Autoloader，而是最终会有许多自动加载器，每个标准一个，这使得您的应用程序更难以维护和调试（因为每个人都可以使 erors ）。