ProBiotekКак тогда реализовать DI в ситуации,когда у нас в DLLке есть интернальные классы, имеющие смысл внутри только этой DLLки ?

С помощью концепции модуля. Именно так и делается, даже в рамках одного приложения и нескольких DLL. Каждый модуль (каждая DLL) сама себя регистрирует в контейнере, свои зависимости. И как раз регистрируются интернальные имплементации публичных интерфейсов. Если интерфейс тоже интернальный, то за пределами модуля всё равно эту зависимость не получить.

Но! Если у разработчика DI головного мозга, когда каждый чих делается через зависимость, то эту болезнь надо лечить, а не искать «решение».

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

ProBiotekПоэтому получается, что фактически да, нужно использовать DI на каждый чих.

Не получается. Приводить такой пример, для которого оправдано применение DI в подтверждение тезиса «на каждый чих», это как доказывать что молотком забивать гвозди — совершенно нормально.

Решать конечно тебе. Но скажу сразу, за повальное применение DI где надо и где не надо, особенно в закрытых модулях как часть внутренней реализации -- по головке тебя за это не погладят. Будешь в джуниорах ходить до старческих штанов. Учись кодить правильно, включай голову!

ProBiotekПросто стало интересно как правильно конфигурировать интернальные классы в DI контейнере, создал темку.

В модулях вместо DI, можно использовать классическую реализацию паттерна Стратегия. Возможно, тебе как раз таки не калькулятор тут нужен, а сам метод вычисления, при чём это не зависимость, а явное требование передать конкретный алгоритм для вычисления (быстрый, медленный, унылый, весёлый...). Ты явно не на том сосредоточился.

winsky!а можно подробнее? просто это такое максималистское заявление. не могли бы вы объяснить почему так категорично?

Что конкретно в этом утверждении не нравится? Давайте обсуждать не характер заявлений (то, как вам кажется), а предметно.

Я могу пояснить, что за всё нужно платить. Если DI позволяет решить малой кровью некоторые проблемы в архитектуре, то злоупотребление им может нанести больше ущерба, чем пользы. Это относится к любым инструментам и методикам.

winsky!я сказал, что утверждение слишком громкое.

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

winsky!какой вред может принести использование паттерна?

употребление DI приводит к новому уровню абстракции, и это усложняет понимание системы. если программист начинает злоупотреблять DI, то прочитать его код становится сложной задачей, а понять — ещё сложнее. стоит ли говорить, к чему это в итоге приводит? об этом хорошо написано у первоисточника, автора этого принципа Роберта Мартина.

чтобы не попасть в ловушку абстракций и не создавать лишней косвенности, переусложнённого дизайна, надо изначально понимать, для чего вообще нужен DI.

вы вот, сможете ответить на этот вопрос?

winsky!т.е. - в каких случаях его применение оправданно, а в каких нет?

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

winsky!эм... давайте определимся. мы говорим о dependency inversion principle или о паттерне dependency injection?

Мы говорим об DI, который в свою очередь является формой IoC в реализации. Смысл говорить о принципах не применительно к коду? Так вернёся к вопросу. Для чего нужен DI?

ProBiotekhVostt,

Вы тоже в своих ответах весьма абстрактны. не привели ни одного примера (а я привел) когда DI не нужен и КАК его заменить, чтобы классы остались достаточно unit-тестируемы (т.е. без тестирования всей кучей с их зависимостями). Как создавать описанные Вами стратегии и как их передавать в класс, который в них нуждается (кто или что этим будет заниматся, если не DI). Это может быть интересно. Может потом действительно можно будет взять на вооружение.

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

Паттерн Стратегия описан очень хорошо на всех языках, гуглится на раз. Зачем я буду пыжиться и демонстрировать вам свои авторские способности по описанию паттернов, если это уже давно сделано и легко доступно? Паттерн Статегия зачастую гораздо лучше решает некоторые задачи, чем DI. Скажу по секрету, есть ещё и другие архитектурные паттерны. Стоит их изучить. И у вас будет много других гораздо более интересных вопросов, чем беспокойство о количестве зависимостей в контейнере.