У меня есть «простая структура», основной экземпляр которой – $ app. Теперь, как лучше всего реализовать автозагрузчик (без использования Composer). Мне нужен класс, который обрабатывает всю автозагрузку (поддерживая различные пространства имен). У меня есть несколько подходов / дилемм.
Сначала я подумал, что должен создать «статический» класс, который обрабатывает все. Но потом что-то пришло мне в голову. Если я использую автозагрузчик перед созданием $ app (который содержит все пути), мне нужно будет определить пути за пределами $ app. А также, если ошибка возникает при автозагрузке класса, я бы не смог правильно обрабатывать ошибку (обработчик ошибок находится внутри $ app и создается после него).
Затем я подумал об инъекции зависимостей, сделав автозагрузчик объектом внутри приложения. Это позволило бы устранить проблему с обработкой ошибок и не требовать от меня жестких кодовых путей или создания их глобальных переменных. Но мне придется загрузить много классов (включая $ app), прежде чем я смогу создать экземпляр автозагрузчика.
Но действительно ли я в мире боли из-за этой проблемы, я не знаю, с чего начать, есть ли какие-то советы, которые я должен учитывать? Можете ли вы объяснить мне, какой метод я должен использовать и почему?
Благодарю.
Если вы пишете фреймворк, вы всегда должны смотреть на существующие, которые должным образом полностью решили вашу проблему. Затем вы получаете вдохновение или просто используете этот компонент. Отличной отправной точкой является symfony, их компоненты разделены и протестированы. Если вы загрузите его композитором или загрузите его вручную, это ваш выбор;)
У них также есть Classloader http://symfony.com/doc/2.0/components/class_loader.html, который вы могли бы использовать в качестве него. Или вы просто посмотрите, каков их подход.
Автозагрузчик (или ваш загрузчик классов) должен быть включен в начале вашего приложения, и это должен быть единственный класс, который вы включаете напрямую.
Если вы хотите загрузить динамический класс, вам нужно взглянуть, как хранятся ваши классы, существуют разные «стандартные» способы, такие как PSR0 http://www.php-fig.org/psr/psr-0/ . Если вы хотите, чтобы ваши пользователи добавляли свои собственные классы, когда они используют вашу инфраструктуру, вам следует рассмотреть возможность поддержки нескольких стандартов.
В результате советов, которые я получил по этим вопросам, я искал немного больше и нашел хорошие ресурсы, откуда их учили.
Автозагрузка – это процесс, в котором программа находит неизвестное имя класса и пытается загрузить его без определения имени класса. Без автозагрузчика это поведение приведет к фатальной ошибке (по крайней мере для PHP). С автозагрузчиком все меняется, и программа будет пытаться загружать Имя класса, не зная, где его найти, но полагаясь на функции или классы, которые считаются для этой цели, эти функции / классы называются автозагрузчиками .
В PHP у нас есть два разных способа достижения автозагрузки (возможно, вам будет полезно прочитать их с сайта PHP ). Первый – это старый __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 решает проблему «гнездования» PSR-0, поэтому вы должны использовать первую. Предположим, у меня есть приложение, и мое приложение опирается на внешние компоненты, PSR-0 следует этому синтаксису:
\vendor\(sub_namespaces\)class_name
Там, где могут отсутствовать пространства_подпрограммы. Но это переводится на полный путь на жестком диске:
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 или прочитать эту красивую статью на сайте.
Если вы были в мире программирования достаточно времени, вы, вероятно, не закончите задавать такой вопрос. Но если это так, вы, вероятно, новый программист, или вы недостаточно программист, поэтому вы должны прочитать этот ответ. В ИТ-мире, и особенно в программировании, стандарты – это почти все. Если бы мы не соблюдали стандарты, мы могли бы даже не иметь видео на наших компьютерах. Если кто-то следует своим собственным стандартам, все будет выглядеть беспорядочно, и в этом случае автозагрузчики станут личными; поэтому вместо того, чтобы иметь один SIMPLE Autoloader, у вас будет много автозагрузчиков, по одному для каждого стандарта, что значительно упростит ваше приложение и отлаживает (потому что каждый может сделать ошибки ).