IOC and computer papers

IOC and computer papers

I. Introduction

IOC-Invertion of Control, that is, Control inversion, is a program design idea. There is no way in the world. When there are more people, there will be a way, this article will show you the evolution of IOC design ideas step by step.

Before learning IOC, we should first understand several concepts.

Dependency): Indicates that a class depends on another class.

Dependency inversion principle (DIP): One of the six principles of the design model is a software architecture design principle.

Control inversion (IOC): A software design principle. The dependency of the upper layer on the lower layer (that is, the acquisition of the lower layer module) is handed over to a third party.

Dependency injection (DI): A method and means for implementing IOC

IOC container: Dependency injection framework, used to map dependencies and manage object creation and lifecycle

Ii. Dependency

Dependency is associated, and dependency is used. The following is a simple example.

Class BMW {public string Show () {return "BMW" ;}} class ChinesePeople {private bmw BMW = new BMW (); public void Run () {Console. writeLine ($ "open {bmw today. show ()} Work ") ;}} class Program {static void Main (string [] args) {ChinesePeople people = new ChinesePeople (); BMW bmw = new BMW (); people. run (); Console. read ();}}

View Code

In the above example, the Chinese people drove BMW to work. There were two objects on the client: Chinese people and BMW cars. The Chinese people used BMW cars. We can find three dependencies:

Client dependent object ChinesePeople;

Client dependent object BMW;

ChinesePeople depends on the object BMW;

Iii. Dependency inversion principle

There will be new demands in a few days. The Chinese will not only drive BMW to go to work, but also drive merbenz to go to work. If we follow the above method of direct dependency, we will need to modify the ChinesePeople class, let it implement a parameter for BMW's heavy load method Run (). Obviously this is not a good design. We can't add a new car every time (that is, modify the lower layer module) it is too troublesome to modify the ChinesePeople class (compared to the upper-layer module of the car...

A Brief Analysis of the coupling relationship is the dependency relationship. If the dependency relationship is very heavy, it will be difficult to maintain the expansion. The less the coupling relationship, the more stable the system will be, and therefore less dependencies.

Definition: A. The high-level module should not depend on the underlying module, and the two should depend on abstraction.

B. abstraction should not depend on details, but on abstraction.

In this figure, we find that high-level module-defined interfaces do not directly depend on lower-level modules. Lower-level modules are responsible for implementing high-level module-defined interfaces. The following code is demo:

Interface ICar {string Show ();} class BMW: ICar {public string Show () {return "BMW" ;}} class BenZ: ICar {public string Show () {return "Benz" ;}} interface IPeople {void Run (ICar bmw);} class ChinesePeople: IPeople {public void Run (ICar bmw) {Console. writeLine ($ "open {bmw today. show ()} Go to work ") ;}} class Program {static void Main (string [] args) {ICar carBMW = new BMW (); ICar carBenZ = new BenZ (); IPeople people = new ChinesePeople (); people. run (carBMW); people. run (carBenZ); Console. read ();}}

View Code

Analysis: In the code above, the ChinesePeople class no longer depends on specific cars, but on abstract cars. In this way, Chinese people can drive to work regardless of their car brands, and the ChinesePeople class does not need to be modified. Think about whether this is good. We can conclude that the upper layer is no longer dependent on details, and the interface orientation is better than implementation orientation, because abstraction is more stable than detail.

Iv. Control reversal

In the above example, we have achieved the isolation between specific people and specific cars. The specific person is only related to the interface of the car. But in Program, the specific object in the main method is dead, and the control is reduced. When I want to modify the Americans to go to work in Ford, I have to modify the code. How can I transfer the control?

The following is a simple example:

Interface ICar {string Show ();} class BMW: ICar {public string Show () {return "bmw" ;}} interface IPeople {void Run (ICar BMW );} class ChinesePeople: IPeople {public void Run (ICar bmw) {Console. writeLine ($ "open {bmw today. show ()} Go to work ") ;}} class Program {static void Main (string [] args) {string people = ConfigurationManager. deleetask[ "people"]; string car = ConfigurationManager. appSettings ["car"]; Assembly assemblypeople = Assembly. load (people. split (',') [1]); Assembly assemblycar = Assembly. load (car. split (',') [1]); Type typepeople = assemblypeople. getType (people. split (',') [0]); Type typecar = assemblypeople. getType (car. split (',') [0]); IPeople ipeople = (IPeople) Activator. createInstance (typepeople); ICar icar = (ICar) Activator. createInstance (typecar); ipeople. run (icar); Console. read () ;}}<? Xml version = "1.0" encoding = "UTF-8"?> <Configuration> <startup> <supportedRuntime version = "v4.0" sku = ". NETFramework, Version = v4.5 "/> </startup> <appSettings> <add key =" people "value =" MyIOC_IOC.ChinesePeople, myIOC_IOC "/> <add key =" car "value =" MyIOC_IOC.BMW, MyIOC_IOC "/> </appSettings> </configuration>

View Code

In the code above, we use reflection + configuration file to transfer control of object creation to the configuration file. This is the so-called control inversion.

Analysis, control inversion is to give control of object creation to a third party, it can be an IOC container, it is equivalent to the factory, what object we want, what object the factory gives us, in this way, the dependency relationships (people and vehicles) depend on the IOC container to establish the dependency between them through the IOC container. (The dependent object is not directly obtained from the new class of the dependent module)

V. Dependency Injection

As we have mentioned above, we have learned that control is transferred. This is our purpose. configuration file + reflection is an implementation, while dependency injection provides an idea, or the IOC implementation method.

Dependency injection is to create and bind an object to the external part of the dependent object. In the dependency relationship, the creation and binding of the BMW Class Object dependent on the ChinesePeople class is executed within the ChinesePeople class. Obviously, this method is not desirable, so how can we transmit the reference of the BMW class to the ChinesePeople class?

Method 1 constructor Injection

Interface ICar {string Show ();} class BMW: ICar {public string Show () {return "BMW" ;}} class ChinesePeopleContructor {private ICar _ car; public ChinesePeopleContructor (ICar bmw) {_ car = bmw;} public void Run () {Console. writeLine ($ "open today {_ car. show ()} Go to work ") ;}} static void Main (string [] args) {ICar car = new BMW (); ChinesePeopleContructor people = new ChinesePeopleContructor (car); people. run (); Console. read ();}

View Code

Analysis: The creation and binding of BMW objects are transferred to the outside of the ChinesePeople class to remove the coupling between the two objects. When you need to go to work on a Mercedes-Benz, you only need to define a Mercedes-Benz class and re-bind the dependency externally. You do not need to modify the interior of the ChinesePeople class, that is, the Chinese people need to go to work first.

Method 2 Property Injection

Interface ICar {string Show ();} class BMW: ICar {public string Show () {return "BMW" ;}} class ChinesePeopleProperty {private ICar _ ICar; public ICar IC {get {return _ ICar;} set {_ ICar = value ;}} public void Run () {Console. writeLine ($ "open today {_ ICar. show ()} Go to work ") ;}} static void Main (string [] args) {ICar car = new BMW (); ChinesePeopleProperty people = new ChinesePeopleProperty (); people. IC = car; people. run (); Console. read ();}

View Code

Analysis: Property injection transmits dependency by assigning values to the property.

Method 3 interface Injection

Interface ICar {string Show ();} class BMW: ICar {public string Show () {return "BMW" ;}} interface IDependent {void SetDependent (ICar icar );} class ChinesePeopleInterface: IDependent {private ICar _ ICar; public void SetDependent (ICar icar) {_ ICar = icar;} public void Run () {Console. writeLine ($ "open today {_ ICar. show ()} Go to work ") ;}} static void Main (string [] args) {ICar car = new BMW (); ChinesePeopleInterface people = new ChinesePeopleInterface (); people. setDependent (car); people. run (); Console. read ();}

View Code

Analysis: The interface Dependency defines a method for setting dependencies, and is inherited by the dependent class to implement this interface.

Vi. IOC container

The IOC container is a DI framework. The main functions are as follows:

1. dynamically create and inject dependency objects;

2. Manage object Lifecycle

2. ing Dependencies

Common IOC containers: Spring. NET, Castle Windsor, Ninject, Autofac, and Unity...

The ioc container provides many rich APIs. Due to the time and space relationships, I will learn about Unity as one of the IOC containers in the next blog. Please wait for a while...

 

If you don't work hard, you will never know the gap between yourself and others. As a cainiao, I believe that the best way to success is persistence, learning, and summarization.

The copyright of this article is shared by the author and the blog Park. You are welcome to reprint it. Please indicate the source for reprinting. Thank you for reading this article.