После прочтения PSR-4, Я думаю, что он просто подойдет для небольших пакетов, в которых мало каталогов.
Если пакеты большие, у него будет так много функций автозагрузки для загрузки из подпакетов. (потому что мы должны сначала сообщить функции базовый каталог)
Рассмотрим CMS или Framework
PSR-0 лучше для этого пакета CMS, чем PSR-4?
Хорошая ли у меня структура каталогов?
Должны ли интерфейсные и абстрактные классы иметь свой собственный каталог?
PSR-4 только для небольшой упаковки?
Нет, PSR-4 предназначен не только для небольших упаковок. Стандартные фреймворки, такие как Zend и Symfony, также используют его.
PSR-4 описывает спецификацию для автозагрузки классов из файловых путей.
Он не делает никаких предположений о размере вашего проекта. Он полностью совместим и может использоваться в дополнение к любой другой спецификации автозагрузки. Это означает, что вы также можете использовать PSR-0.
PSR-0 лучше для этого пакета CMS, чем PSR-4?
Это зависит. Если ваша система использует пространства имен, чтобы избежать конфликтов имен классов с другими поставщиками, то PSR-4 является правильным выбором. Но в целом: автозагрузчику все равно, он просто ест классы PSR-0 и PSR-4 на завтрак.
Если вы действительно хотите знать: проведите A / B-тест и сравните скорость автозагрузки.
Хорошая ли у меня структура каталогов?
Это зависит: если вам и пользователям вашей CMS или Framework нравится структура, то да. Если вы работаете с Composer для управления зависимостями, то, вероятно, lib\ framework
мертвая лошадь, потому что все пакеты живут внутри vendor
папка. Если вы разрабатываете CMS, то эта структура зависит от поставщика.
Должны ли интерфейсные и абстрактные классы иметь свой собственный каталог?
Я бы предложил сохранить интерфейс или абстрактный базовый класс в том же каталоге.
Это сохранит вам одну папку) только для одного или двух файлов.
Других решений пока нет …