Over the weekend, I was reading “Deep Understanding of Java Virtual Machine”, in which there was a description of Java virtual machine, and I suddenly got inspired. I felt that I could explain the principle of dependency inversion design from this perspective.

I first came across dependency inversion in the book HeadFirst Design Patterns. Since then, WHENEVER I re-engineer a business or start a new project, I have read this book first, often with new insights.

Java Virtual Machine specification and language specification

When Java was first born, it was famously advertised as “Write once, run anywhere.” “Has nothing to do with the platform of” ideal eventually on the application layer of the operating system: Sun Microsystems and released many other virtual machine suppliers can run on different platforms of virtual machine, the virtual machine can be loaded and executed the same bytecode that is independent of the platform to implement the program of “write once, run anywhere”. VMS on different platforms use the same program storage format — ByteCode — as all operating system platforms, which is a cornerstone of platform independence.

With the Java language, programmers can ignore specific operating system platforms (Win, Mac, Linux, etc.), ignore specific hardware underlying instruction sets (x86, ARM, etc.), and simply focus on the Java language specification and “write once, run anywhere.”

Second, the dependence inversion of programming thinking

2.1. Before the Java language:

Programmers need to rely on specific operating systems to do specific jobs. For example, to draw a circle, it is necessary to call the GUI drawing library of different operating systems to complete it. The library name and API interface are different, which need to be adapted in the code.

In terms of dependencies, high-level applications depend on low-level operating system drawing libraries.

Every time you add a new platform, you are adding a new dependency on a drawing library. In addition, subsequent changes or adjustments to the drawing library API will also need to be made to the higher-level application.

2.2. After the Java language came out:

Programmers rely only on the Java language specification to get things done, regardless of the platform. For example, draw a circle, call the API of the Java GUI library, and the Java virtual machine interconnects with a particular operating system platform to draw a circle.

In terms of dependencies, high-level applications rely on Java virtual machines or language specifications, and low-level components also rely on Java virtual machines or language specifications for functional connectivity.

Every time a new platform is added, as long as it supports the Java Virtual Machine or language specification, nothing changes, and the platform’s drawing library API changes or changes, and the higher-level applications do not need to change either.

Before and after the advent of the Java language, the way of thinking about programming also changed. From high level components to low level components, both high level components and low level components depend on abstractions, in this case the Java Virtual Machine or language specification, or Java Virtual Machine.

Third, what is the relationship between this and our dependency inversion design principle?

In fact, the above development thinking is the “dependency inversion” design principle, the dependency inversion design principle has several different statements as follows:

  • Rely on abstractions, not concrete classes
  • Program for interfaces, not implementations.
  • You can’t have a higher-level component depend on a lower-level component; both should depend on abstraction.

When I first came into contact with this design pattern, I was most puzzled by the principle of inversion. Where is the inversion?

“Inversion” in the dependency inversion design principle refers to the complete opposite of the general object-oriented way of thinking. In normal thinking, start with the top design and work down to the concrete low-level class design. The dependency inversion design principle requires us not to start at the top, but to see what we can “abstract” first.

conclusion

In practical cases, it is very difficult to apply the inverted design principle perfectly, especially in the engineering architecture design of new business, and the abstract model will gradually become “clear” after the business has been stable for some time.

More commonly, new requirements cannot be iterated over old business architecture implementations and architectural design changes have to be made (the first goal of architectural changes is to make the business look exactly the same before and after the changes, as if nothing had happened to the users). Since no new increments are generated, no architectural changes are made unless necessary).

Step on the pit, will realize the dependence of inversion of the powerful, do not say, say more are tears.

The resources

  1. Head First Design Mode (Chinese Version) — Freeman (E)

  2. Big Talk design Patterns by Cheng Jie