Saturday, 21 May 2016

Dependency Inversion Principle: Part 5 - Using DIP/IoC container

(Note: you should read Part4 - Refactoring Using DIP before in order to understand this section)

I can just stop after refactoring code in previous section. I don't really need to use a DIP/IoC container. However most containers will have some additional features which enable us to tidy up the class composition code. You can even write your own IoC container with the features you really need.

Dependency Inversion Principle: Part 4 - Refactoring Using DIP

You have known the basic concepts of DIP, now it is time to apply it to the code. If the code is written without DIP principles, this means the code needs a refactoring by abstracting and inverting the dependencies. The code will normally have many interactions between classes. This mean that a class may have dependencies, but in turn the class will be the dependency of other class.

Refactoring the code using DIP will eventually create a tree structure which represents the class composition. Normally there will be one composition root, which is the class at the top of the tree.

Dependency Inversion Principle: Part 3 - Dependency Inversion Methods

After various parts of the class have been abstracted, the next thing to do is inverting the dependencies. The actual implementation of the abstraction, or dependencies, need to be provided from outside of the class. By doing so, the class now does not depend on the implementation, but only the abstraction of it.

Dependency Inversion Principle: Part 2 - Abstraction Methods

The first activity in implementing DIP is to apply abstractions to the parts of the codes. In C# worlds, there are a couple ways to do this:

Saturday, 7 May 2016