Декларация

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

Я бы вряд ли это принял к сведению

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

исправь ошибку пожалуйста. Либо "классЫ", либо "описанныЙ"

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Все тоже самое, что я и раньше писал.

Мощь - гибкое управление зависимостями, как и в любом другом контейнере. Простота - минималистичное api, простое конфигурирование, минимальное количество кода для использования зависимостей в классе.

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

А вот теперь я не понял... Какой то сюр.
Во первых, ты не можешь внедрить зависимость в класс. Во вторых, класс нельзя инициализировать. И то и другое можно сделать только с объектом, если точнее - с экземпляром класса.

И тут вообще полная путаница. Дело в том, что прямое, как бы не единственное предназначение контейнера зависимостей - именно инициализация. Другими словами - сборка необходимого модуля (принято говорить - сервиса). И его прямая задача - собрать сервис из зависимых друг от друга объектов. Делается это для того, что бы ослабить связанность кода, для того, что бы можно было безболезненно изменять/заменять зависимости изолированно друг от друга. Дабы соблюсти принцип D из SOLID.

Не хранение сервисов (DIC может вообще не хранить объекты, это экономически выгодно), и уж не приведи господи - передача контейнера параметром в какой то конкретный класс. А именно сборка. Причем в идеале на каждый сервис должен быть свой экземпляр контейнера.

Если ты создаешь экземпляр класса до контейнера, а только потом внедряешь в него зависимость, это уже не контейнер по определению. Это в лучшем случае сервис-локатор.

Еще раз. Контейнер, это видно из названия, это упаковка классов, зависимых друг от друга. Полуфабрикат. Сервис. По сути это похоже на фабрику или билдер, с той разницей, что последние строят сервисы динамичски, в процессе выполнения кода, а DIC конфигурируется статически, один раз. Часто даже через конфигу.

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

Дело в том, что отличие DIC от локатора нельзя найти в отрыве от контекста. Их отличие именно в использовании.

А если ты внедряешь

то почему это гордо называется DIC? Тут либо трусы снять, либо крестик надеть

Так что в настоящем DIC использование конструкторов - то, что доктор прописал. Это удобно, потому что все в одном месте, не размазано по сеттерам, и уж тем паче по публичным свойствам.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Минусы внедрения через конструктор:

1. Количество аргументов в конструкторе может стать неразумно большим;
2. Для внедрения через конструктор все также нужны свойства, с той разницей что эти свойства будут защищенными, то есть программист обязан не только описать свойства, но и в конструкторе написать маппинг;
3. Давая разработчику право сделать передачу зависимости не обязательной мы приходим к ситуации "комбинаторного взрыва". Безусловно проблему можно решить при помощи декларации правил разработки по обязательности зависимостей при внедрении через классы. Но давай на чистоту, что такой подход в худшем случае нарушит тот кто это правило задекларировал, а в лучшем случае это будет периодически выскакивать на ревью.

К сожалению, эти все 3 минуса для меня являются жирными. Не могу терпеть большое количество аргументов, манки-коддинг и неоправданную сложностью.

При внедрении через свойства, ПРИ ПОМОЩИ МОЕГО КОНТЕЙНЕРА (про другие я не говорю), эти 3 минуса решены:
Количество свойств в классе меня не смущает;
Как минимум не нужно писать маппинг в конструкторе;
Все зависимости, что задекларированы, являются обязательными;

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

Может. Но это скорее относится к ошибке архитектуры. Кроме того, давно придуманы DTO.

Количество свойств будет тем же, другой вопрос, что они у тебя публичны. Прямое нарушение SOLID.

Вот маппинг как раз и нужен для простоты поддержки. Если есть маппинг, сразу видно: что, где и откуда. Маппинг решает и следующий вопрос:

Написав один раз мапку в конструкторе, мы делаем зависимости обязательными, а главное код прозрачен. Не нужно бегать и искать, где используется зависимость. А особенно у тебя, где свойства раскиданы не только по классам, но и по трейтам.

Поддерживать такой код - адъ и израиль. И ради чего? Ради экономии пары секунд на мапке?

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Мы оба понимаем что я "опустил" слово экземпляр. Мы оба понимаем что под "инициализировать" я имел "создать экземпляр класса". Что за буквоедство, или для тебя это важно? Почему, что это меняет, если ты все равно понял что я написал?

Тут ты безусловно прав. Я просто похлопаю. Только зачем это писать? Количество экземпляров классов(исключая выбрасывание исключений), которые я инициализирую вручную вряд ли привысит 10 штук, и основанная часть их находится в классе который занимается запуском и инициализацией приложения, то есть в тот момент когда сам контейнер еще не подключен.

Хранить зависимости не обязанность DIC - согласен, это личное дело мисс инкапсуляции. Про передачу контейнера параметром в конкретный класс не очень понял, что ты имеешь ввиду? По поводу "сервиса" тоже не понимаю, что ты имеешь ввиду, что такое сервис в твоем понимании и почему у него должен быть каждый раз новый экземпляр контейнера? Если ты имеешь ввиду сервис локатор, то мой контейнер делает каждый раз новый сервис локатор и внедряет его через сеттер если видит что зависимость реализуем необходимый интерфейс.

Тут ты и прав и не прав одновременно. Поясню, если рассматривать ситуацию с точки зрения того что происходит с объектами - ты прав, мы положили объекты в какой-то контейнер, с той целью что потом где-то достанем, типичный сервис локатор. Но тут ты не учитываешь один момент, эти переданные объекты контейнер будет внедрять сам, при этом конечный объект(которому контейнер внедряют зависимости) вообще не будет в курсе, что вот то свойство это объект который был запихан в контейнер вручную при инициализации, так как для контейнера нет разницы, в том что он сам собрал объект или программист положил его туда при создании экземпляра контейнера.

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

Делаешь заявления, то и аргументируй, расписывай почему так.

Манипуляция на эмоции, ммм дэлишес. Гордо? Я вроде не писал, с "гордостью представляю вам". Ты привел аргументы так, что я их не понял, сделал какие-то непонятные мне выводы. Я готов их понять, не говорю, что принять, но проблема в том, что в последних твоих предложениях я даже не могу понять твоей точки зрения.

Мы оба с тобой знаем, что удобно это субъективная вещь, а в разработке кода лучше полагаться на объективные вещи, иначе придется команде втирать "какую-то дичь", вместо того что бы показать, что это объективно вот так, это не хорошо или плохо, а вот так. По поводу конструкторов я уже выше писал, объективные минусы есть, для тебя они возможно не столь критичны, для меня критичны.

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