Повышаем читаемость Symfony DI

[bondeg]

Выглядит по большей части как выдуманные проблемы.

1. Autowire - никто не запрещает использовать совместно с ним конфиги с явной передачей аргументов. При этом необходимость в таком относительно основной массы бизнес логики как правило ничтожна.

2. Классы вместо алиасов - аналогично, нет никаких проблем в использовании алиасов совместно с классами, более того, так даже более явное поведение, т.к. сразу видно, что раз у нас тут алиас вылез - значит этот класс имеет несколько разных поведений в зависимости от конфига.

[Sanchous98]

Плюс выдуманная проблема с разными реализациями. Autowiring не работает с интерфейсами в том смысле, в котором автор пытается их использовать, то есть класс не зарегистрируется под интерфейсом. Это надо будет сделать вручную в любом случае

[karrakoliko]

если есть только одна реализация интерфейса - зарегистрируется.

когда появится вторая - начинается неприятная возня с ручным разруливанием

[ToshaSieg]

• "иначе зачем мы создавали интерфейс" - для инверсии зависимостей и независимой разработки юнита.

• "добавив всего одну строчку di..." - не нужно эту одну строчку добавлять, если она там не нужна.

[asmdk]

Вы предлагаете просто добавлять еще больше конфигов заранее, когда это еще не нужно, кстати может поэтому они у вас и разрастаются.

1. Автовайринг отлично работает, и если у вас только одна реализация сервиса, не вижу смысла прописывать ее вручную, например когда у вас появится еще одна реализация, это может быть замена текущей, а не вторая, тогда все просто, удаляете предыдущую и все работает без правки конфигов. Если же добавляется новая реализация и вы используете две, то тогда вы например можете одну реализацию прописать на интерфейс, как по умолчанию, а вторую прокинуть вручную в нужные классы, в отличии от того что предлагаете вы, это намного уменьшит конфиги.

2. Классы вместо аргументов, таже проблема, вы увеличиваете конфиги, когда это не нужно, и в моей практике классы для которых нужно 2 сервиса с разными аргументами встречаются намного реже, и опять же когда это понадобиться можно использовать такой вариант и стить останется одинаковый: App\Service\SiteUpdateManager: arguments: $adminEmail: '[e-mail]'

3. Интерфейс вместо реализации: опять же смотрите первый пункт, интерфейс позволяет очень легко менять реализацию, либо устанавливать реализацию по умолчанию

[sl0]

3. Более того, если вдруг потребуются разные реализации, например, для разных сред, то приколоченную гвоздями реализацию легко можно забыть в конфиге.

[asmdk]

я еще забыл написать что разные реализации можно глобально биндить на интерфейс + имя переменной, типо такого, за точность не гарантирую, в доке надо смотреть:

bind:

LockInterface $filelock: App\Component\FileLock

LockInterface $memoryLock: App\Component\MemoryLock

соответственно инджектить так же LockInterface $filelock, заинджектит FileLock, LockInterface $memoryLock - MemoryLock соответственно...