IoC outside Framework

What is IoC (Inversion of Control? The Software Design master has made many definitions. Here, I will talk about IoC from the perspective of Component development-"IoC is a design mode. When the system is composed of multiple components (Component, it can eliminate the direct dependency between components and make the development of components more independent and flexible ".

IoC is the basic feature of the Framework, but IoC is not designed specifically for the Framework. It can play a role in the areas where you need to eliminate component dependencies.

The following is a development example: a calculator component needs to be developed to implement integer addition operations. The calculation process records logs.

To meet the above requirements, we developed the 1st Edition program:

Using Log;

Namespace Todd
{
Public class Calculator
{
Public int Add (int a, int B)
{
Logger. Instance. Log (String. Format ("input: {0}, {1}", a, B ));
Int c = a + B;
Logger. Instance. Log (String. Format ("result: {0}", c ));
Return c;
}
}
}

The above program is compiled into the Calculator. dll component, which will reference another component Log. dll (which may be a third party or self-developed ). The problem is:

A. Calculator. dll is a direct dependency on Log. dll. The development of Calculator cannot be performed independently without Log. dll;

B. If other components User. dll need to use the Calculator function, it must reference Log. dll in addition to Calculator. dll. User. dll may only need the addition function of Calculator, and does not need to record logs, or wants to redirect logs to other places. However, the log dependency is firmly pinned inside Calculator, resulting in User. it is inconvenient to use Calculator for dll.

Through IoC, we can solve the above problem. The following is version 2nd:

Namespace Todd
{
Public class Calculator
{
Public delegate void Log (string message );

Public Log Logger;

Public int Add (int a, int B)
{

If (null! = Logger) Logger. Invoke (String. Format ("input: {0}, {1}", a, B ));

Int c = a + B;

If (null! = Logger) Logger. Invoke (String. Format ("result: {0}", c ));

 

Return c;

}

}
}

 

As shown in the code above, Calculator still has the Log logic, but it no longer directly depends on Log. dll. It gives the option of depending on the specific Log to User. dll:

Using Todd;
Using Log;

Namespace Test
{
Public class User
{
Public void Use ()
{
Calculator cal = new Calculator ();

Cal. Logger = Logger. Instance. Log; // inject dependency

Int r = cal. Add (1, 2 );

Console. WriteLine (r );
}
}
}

With IoC, the development of Calculator becomes independent in version 2nd, and the use of Calculator becomes flexible.

Further Thinking: Why does Calculator use delegate instead of interface to express the Log function? What are the problems with using interfaces? If you are interested, you can discuss it from the perspective of actual development and usage!

The beginning of this article defines IoC, and finally defines IoC from the perspective of dependency abstraction and specific dependency establishment: "IoC is a design model, components in the IoC mode abstract dependencies through interfaces or delegation to eliminate direct dependencies on other components. The specific dependencies are established by the component users ".

I am a beginner in. Net. please correct me if I have any mistakes in this article! You are also welcome to share your thoughts on IoC!