Мне кажется вы чутка перегибаете. Пускай падает в рантайме, если что. Это будет отловлено ещё на этапе разработки. И падать оно будет только если автор был пьян.
А дело тут всё же не в гибкости, ИМХО. Это экономит кучу времени. В т.ч. и при юнит\интеграционном тестировании, помимо разработки.
Dependency Injection скрывает реализации от нас, а также от компилятора, что явный минус.
Почему минус? Зачем компилятору знать реализацию? Чем ему это мешает? Не понимаю. Где-то в другом месте проекта есть класс-реализация моего интерфейса, компилятор его найдёт и скомпилирует. Зачем ему что-то ещё? А если реализации нет, то не скомпилируется код, где происходит инициализация контейнера.
И еще скрывает от нас в плане читаемости кода. Была бы фабрика, я бы быстро нашел в коде, что за тип используется (ну бывает, надо ходить по коду и смотреть, как он устроен)
Зачем знать, как устроен конкретный тип? Вам дали интерфейс (контракт) — пользуйтесь. В его кишки лезть совершенно не нужно, вы лишь клиент. Подобное очень-очень опасно. Это же основы ООП, абстракция и инкапсуляция.
Но тогда любой внешний код при создании ProductService, должен знать то, что должно быть скрыто, а именно: что класс ProductService использует IProductRepository. С чего вдруг? Это кишки сервиса. И что он кушает, нам не важно, важно что он для нас делает. И банально, если этот сервис часто создается, кругом будет дублирование кода.
Это, кстати, софизм :) Если внешний код создаёт ProductService, то он обязан знать, как и из чего его создать. А вот если он просто пользуется уже готовым экземпляром — тогда замечание резонно, знать об интерфейсе (или реализации) совершенно не нужно.
Да, но это по-моему не отличается от простого выдёргивания сервера из розетки, если там вообще нет никакого кэша. Мы действительно теряем всё, что только собиралось записаться на диск.
Почему после аварии кэш — невалиден? На SSD лежат метаданные — какие блоки dirty, какие нет. Запись в обход кэша на диск не производится. Почему бы просто не продолжить работу после ребута?
Такое ощущение, что UI делали впопыхах или силой младших разработчиков без контроля старших. Подписи (даты) на графиках — ужас. Формат даты в выборе периода — нестандартный, текст «Действует до» в настройках времени ссылки явно не согласован с последующими пунктами. Мне бы было стыдно выкатывать подобное для публики.
Вы меня не до конца поняли. Я в своём комментарии написал, что без тестов — возможно архитектура и будет оптимальнее и производительнее. Возможно. Но с тестами она точно будет яснее, нагляднее, проще и дешевле в поддержке. Так что с вашим мнением я совершенно согласен :)
Про архитектуру: быстрее и оптимальнее может быть, но дешевле в сопровождении — вряд ли. В современном мире важнее скорость и стоимость разработки, поддержки, нежели оптимальность и производительность.
А остальное — приложится. Мир!
А дело тут всё же не в гибкости, ИМХО. Это экономит кучу времени. В т.ч. и при юнит\интеграционном тестировании, помимо разработки.
Почему минус? Зачем компилятору знать реализацию? Чем ему это мешает? Не понимаю. Где-то в другом месте проекта есть класс-реализация моего интерфейса, компилятор его найдёт и скомпилирует. Зачем ему что-то ещё? А если реализации нет, то не скомпилируется код, где происходит инициализация контейнера.
Зачем знать, как устроен конкретный тип? Вам дали интерфейс (контракт) — пользуйтесь. В его кишки лезть совершенно не нужно, вы лишь клиент. Подобное очень-очень опасно. Это же основы ООП, абстракция и инкапсуляция.
Это, кстати, софизм :) Если внешний код создаёт ProductService, то он обязан знать, как и из чего его создать. А вот если он просто пользуется уже готовым экземпляром — тогда замечание резонно, знать об интерфейсе (или реализации) совершенно не нужно.
где лишняя запятая не даёт с первого раза понять смысл предложения. Исправьтесь, пожалуйста!
А за пост ещё раз спасибо :) И вас тоже с наступающим