“This is the fifth day of my participation in the August More Text Challenge. For details, see: August More Text Challenge.”
preface
At the top end of the interview, often encounter some questions about design patterns, each time the answer is not ideal. Coincides with the more challenging activities in August, I am prepared to spend a month to get a good understanding of design patterns, so as to increase my confidence for the interview.
Before learning about design patterns, it is important to recognize that design patterns are programming ideas that can be applied to any programming language. The second is to start with the principles of design patterns, so this article will detail one of the principles of design patterns relies on the inversion principle.
The official definition of
High-level modules should not depend on low-level modules. Both should rely on abstraction.
Abstraction should not depend on details, details should depend on abstraction.
Your own understanding
First of all, let’s take a few real-life examples to understand the high and low level modules.
Computer host everyone is very familiar with it, the host has a motherboard, CPU, memory, graphics card, hard disk, the motherboard belongs to the high-level module, CPU, memory, graphics card, hard disk belongs to the low-level module. This attribution is based on a certain basis, low level modules have changeability, high level modules are not easy to replace. Imagine, to change a motherboard, to the CPU, memory, graphics card, hard disk removed, and then replace the motherboard, to move to all accessories. So for a memory, as long as the memory from the motherboard to replace down on the line.
Here is another example to further understand how hard high-level modules are to replace and how easy low-level modules are to replace. Suppose you open a milk tea shop, where the milk tea shop is a high-rise module, the milk tea sold is a low-level module. When business is bad, it is easy to change several kinds of milk tea to sell, or to reopen a milk tea shop.
The high-level module can be regarded as a platform, and the low-level module can be put on this platform to realize its function. For example, the CPU, memory, graphics card, hard disk installed on the motherboard to its role, the milk tea in the milk tea shop to sell.
Once you understand what high level modules and low level modules are, understand why you rely on inversion and how inversion works. Let’s take the example of opening a milk tea shop.
Suppose you want to open a milk tea shop, according to normal thinking, first want to open a shop where, how many employees to hire, and finally decide what milk tea to sell. However, some bosses think too much and think of how to produce milk tea. This is putting the cart before the horse. It should be that milk tea depends on milk tea shops to sell, so it should be inverted. This is also to rely on the inversion principle of the high-level module should not rely on the low-level module, milk tea shop should not rely on milk tea, milk tea types are thousands of thousands, the biggest change to a kind of milk tea.
As mentioned above, milk tea depends on milk tea shops to sell, and it should be added that milk tea should not be a milk tea shop. This milk tea shop closed down, and it is sold in another milk tea shop. So the milk tea shop and milk tea are not interdependent, this is not good. According to the principle of inversion of the two should rely on the extraction, the hundreds of thousands of milk tea extraction like a extraction like class, the milk tea is a specific class, the provision of milk tea in this specific class to provide a sell method to sell the milk tea, then you can put this method out of the extraction like class. Milk tea shop as long as the abstraction of the class, inheritance it instantiated out of a specific class, call the sell method inside to sell milk tea on the line, don’t care how milk tea production.