# Delphinum (20.01.2017 / 21:11)Тут далеко не для любого проекта.
На деле вариант 2 более распространен, потому что ты не издаешь стандарты чтобы пользовать вариант 1, ты пишешь готовые решения, которыми будут пользоваться. Другими словами если ты будешь создавать п
Если пишешь простой движок на спагетти-коде с частичным использованием ООП, или юзаешь простые фреймворки, типа Godeigniter, Yii ну или другие, но в традиционном стиле, то тут речь не идет.
Я же имел в виду самый современный подход, где центром системы является контейнер сервис-локатор, работающий на конфигах. Пример: https://github.com/john-cms/jo ... p#L20
Когда мне нужен переводчик, я знаю, что у меня для этого в API есть интерфейс Translator\TranslatorInterface::class я его из контейнера и требую. А уж контейнер сам выдаст нужную реализацию, которая была у него прописана в конфиге.
API нет смысла дробить по пакетам, ибо реализация может меняться.
Вдруг я завтра вообще захочу заменить один пакет другим, более надежным, но реализующим тот же интерфейс. Модули этого и не заметят.
Посему, чем выискивать API по пакетам, логичнее собрать все интерфейсы в одном пакете.