Getting Started 02 - Control Inversion IOC
IOC full-name Inversion of Control, if the Chinese is hard to translate, it is "control reversal". At first glance, it is not easy to understand its significance from the literal, I think Io can be learned from Dependency Inversion, which is the reversal of dependencies. Dependency Inversion has a clear explanation in this article: http://www.objectmentor.com/publications/dip.pdf
Simply put, on the design of the module, the high-level abstract module is usually related to the business-related module, which should be reused without relying on a low-level actual module, for example, if the low-level module is originally a floppy disk access mode, and the high layer The module is a demand for a storage backup. If the high-level module is directly called the low-level module, it produces a dependency. For example, for example, the following program:
#include
....
Void save () {
....
Savetofloppy ()
}
}
Since the Save () program depends on SaveTofloppy (), if it is necessary to replace the low-layer storage module for a USB disc, this program has no way to reuse, must be modified, the overall module must be followed by high-level modules. Dividing, this is not a good design, we want the module to rely on the abstraction of the module, so that you can reuse the high-level business design. If the object-oriented manner is designed, the interpretation of the dependency inversion becomes the procedure should not rely on the actual, but depending on abstraction, the actual must depend on abstraction. Let's take a look at this Java program:
BusinessObject.java
Public class businessObject {
Private floppywriter Writer = new floppywriter ();
....
Public void save () {
...
Writer.savetofloppy ();
}
}
In this program, BusinessObject's storage depends on the actual floppywrit, if we want to change the storage to the USB disc, we must modify or inherit your businessObject to expand, and cannot directly use BusinessObject. This case can be improved if the declaration of the interface can be improved, for example:
Public interface idevicewriter {
Public void savetodevice ();
}
Public class businessObject {
Private ideviceWriter Writer;
Public void setDeviceWriter (IDEVICEWRITER WRITER) {
This.writer = Writer;
}
Public void save () {
....
Writer.savetodevice ();
}
}
In this way, BusinessObject is reusable. If I have the need to store to FLOPPY or USB discs today, I just do my ideviceWriter without modifying BusinessObject:
Public Class Floppywriter IMPLEMENT IdeviceWriter {
Public void savetodevice () {
....
/ / Actually store to FLOPPY program code
}
}
Public Class USBDiskWriter Implement IdeviceWriter {public void savetodevice () {
....
/ / Actually store the program code to USBDisk
}
}
From this perspective, Dependency Inversion means that the program does not depend on behalf, but the procedure and practical depend on abstraction. IOC's Control is the meaning of control. In fact, the meaning behind it is also a transfusion of dependencies. If a depends on B, its meaning is B has control, and we want to transfer this relationship, so dependencies. It is the reversal of the control relationship, with the transfer of the relationship, we can get the reusability of the component. In the above Java program, the entire control is transferred from the actual FLOPPYWRITER to the abstract IDEviceWriter interface, making BusinessObject, Floppywriter, USBDiskWriter These have implemented the abstract IDEVICEWRITER interface. From the perspective of container, the business logic part of the program should be reused, and should not be affected by the framework or container used because we may transfer the entire business logic to other frames or containers, if the business logic is too dependent The container will be difficult to transfer to other frames or containers. IOC's perspective of the container can be used to represent this Hollywood, "Don't call me, I'll call you." In the terminology of the program, "Do not ask the container as you need (object) Resources, the container will automatically give you these objects! " The IOC requires that the container does not invade the application itself, the application itself provides a good interface, and the container can not take the required resource to the program through these interfaces, and the application does not actively require resources to the container, so it will not depend on the container Components, the application itself will not be aware that it is being used by the container, which can be detached from the container without any changes, and this feature is exactly the most needable to some business logic intermediates.
