Thoughts on IOC, low coupling, configuration files and their essential significance

I read a blog about IOC, "do you really know about IOC and AOP?", I feel a little bit.
IOC is not very familiar with IOC, but I feel it can be improved in two ways:
1. Use "injection" to replace functions. The simple "injection" can be implemented through seter or constructor. Then, various injection classes and host classes can be combined in the assembly phase during the runtime. The disadvantage of simple "injection" is that the specific injection class should be written to the assembly method.
2. To solve the problem of simple injection, some people use reflection + configuration files to implement injection. Now, you only need to modify the configuration file to replace the injection class.

The so-called "injection" can be understood as a process in which the host class's resolution/replacement function should be implemented separately as a class, then, the class abstraction (abstract class or interface) is used as an interface of the host class (assign values through seter or constructor ), at last, an instance that implements specific functions is assigned to the host class at runtime. In the preceding implementation, the host class must explicitly indicate the interface type of the injection class, and explicitly add the injection class during the Assembly stage, and then assign it to the corresponding interface of the host class. The benefits of this kind of thing are naturally there, just like the abstractfactory or builder mode: only open interfaces, extract specific implementations, so that you can easily implement replacement of specific implementations. But let's take a closer look.CodeTo the Assembly class.

In the configuration file mode, the assembly of classes is implemented in the form of configuration files, so that the replacement of injection classes can be achieved without modifying the code or compiling. The benefits of doing so are even more obvious. In any case, replacement of code implementation functions without modification can bring good results at least in terms of release. As for how much benefits the code can bring, I think it may be determined by the environment and application scenarios. After all, this is much more complicated than simple implementation. In fact, this implementation transfers coupling from the Assembly Method to the configuration file.

In fact, I spent a lot of effort in IOC implementation to do type Matching ...... The host class corresponds to the injection class interface, which cannot be avoided by a strong language. In this case, the implementation of IOC in a non-typed dynamic language should be very easy and the effect should be good-but at the same time, the negative effect is that type identification and matching can be performed at runtime, which is prone to errors, however, it seems that the configuration file method cannot avoid this problem.

Furthermore, configuration files can also evolve and evolve. First, can the content in the configuration file appear in the form of metadata? OrProgramSet format? This Assembly is actually a replacement of the configuration file or metadata function-although the modification is not convenient, it also brings security assurance. However, we have to deal with compilation problems. A dilemma.

Nowadays, all kinds of configuration files are flooded, so no wonder ror is getting popular. In fact, in the configuration file, it is essentially to transfer the coupling location from unmodifiable compilation code to a modifiable text file, in this way, the "Compilation" link can be removed when some functions are replaced, in order to achieve this effect (I don't know if this is correct ).
Although you don't need to modify the code, you still need to modify the configuration file. I personally feel that this is actually the same thing. After all, if this trend develops to the extreme, I think you can write programs with only the configuration file, and the Host Program degrades to a configuration file interpreter-in fact, this can also be implemented. The host programs of eclipse and sharpdevelop are already such a thing. Isn't adding an interpreter to the xml configuration file a new language? If the configuration file is defined using a script-like method instead of XML, the configuration file is actually an interpreted language. Then, in order to improve the efficiency of this configuration method ...... We made a huge circle and then switched back to the compilation language. From this perspective, this is a balance problem. From a higher point of view, this is a process of spiral evolution, evolution, and rise. From a realistic point of view, the next two decades will be the world of language interpretation and Dynamic Language.

Let's take a closer look at all of this. The reason why we wanted Oo was to reduce the complexity caused by process-oriented packaging problems in large software. With Oo, we found that everything was not so beautiful. In order to reduce the Coupling Degree between objects and increase flexibility, we had a design pattern. People applied the design model and found that debugging is inconvenient and the complexity is improved. IOC can be understood as a pattern, but from another perspective, isn't it an OO implementation of a callback function? We actually switched back to the starting point. Where should we turn next?

In fact, this is another complexity caused by the complexity of software. The difference is that people can choose which complexity they can better accept.