[chunkyfunky]

Page 150 of "Clean Code" says this about the DIP: "In essence, the DIP says that our classes should depend upon abstractions, not concrete details". This is very similar to pretty much any canonical definition you can find anywhere else. I'm quoting it here because the person who coined the principle is the same person whose name is on the book, so I am guessing his definition is correct.

If you're not using abstractions, you are not using the DIP. What is being described here with low-level modules depending on high-level modules is categorically not the DIP, and I am starting to wonder if this is perhaps part of the frustration that the poster we're replying to has experienced with DI, since turning your coupling upside down will have the same problems as just high coupling in general, except everything is upside down now and harder to read :)

[jdmichal]

Is it just the text that's supposed to be upside down:

    ᴉɟ (ɐ == q) {
        ɔ;
    }

Or the whole thing?

    {
        ;ɔ
    } (q == ɐ) ɟᴉ

I want to make sure I do this the right way.

[peheje]

Hi chunkyfunky. I recently read Clean Code, great book.

I agree with your take on DIP.

We're using Microsoft Service Collection and with the Scrutor nuget component we were able to easily decorate an implementation from another package to extend the functionality adhering to the open closed principle OCP.

DI also enables your code to be open for extension but closed for modification.

Great stuff!

[chunkyfunky]

Scrutor looks great, I must take it for a spin! And that is a great point about DI - being able to extend code/behaviour by injecting a different implementation of a dependency