Здравствуйте, Sharov, Вы писали:

S>Подождите, мы DI рассматриваем в контексте IoC контейнеров, где мы в явном виде new никогда не вызываем, а используем,
S>например, абстрактную фабрику. Ну так вот IoC у меня созвучен с dip, в том плане, что это dip для контроля управления.
S>А dip говорит, что завязываться на детали (реализации) плохо, лучше завязываться на абстракции. Т.е. мы куда-то встраиваемся
S>(во фреймворк) через интерфейсы и абстрактные классы.

DIP во многом зависит и от ЯП, и тут есть некоторые нюансы, и Мартин об этом писал, кстати, что в C++ хидер-файл включает все детали класса, включая все его приватные методы или поля, и даже инклюдит соответственно то, что ему нужно для приватных членов, и "настоящее" разделение там проще сделать через наследование от чистого абстрактного класса (считай это интерфейс в Java/C#).

В Java/C# — напротив — мы имеем автоматическое отделение интерфейса от реализации, в добавок с символическим разрешением зависимостей в рантайме. Ты можешь положить в сборку MyClass1 и будешь видеть исключительно его публичный контракт (публичный интерфейс), без каких либо дополнительных телодвижений, а его изменение лайаута — тебя вообще не волнует, рантайм позабоится об этом сам. И таким образом MyClass1 для всех потребителей — и есть уже эта самая абстракция, интерфейс.

Введение же интерфейсов или абстрактных классов в терминах C#/Java — должны уже иметь на это основания: точки расширения в фреймворках, множество реализаций и т.п.