The principle of relying on change in the greatest truths to simplicity

 

Chapter V dependency Switching Principle 5.1 What is dependency Switching Principle

Dependency Switching Principle (Dependence inversion principleDip (alias Dependency inversion principle or dependency inversion principle) has two definitions.

Definition 1:"A. High-level modules should not depend on low-level modules. Both of them should depend on abstraction. B. abstraction should not depend on details, but on abstraction."[1]

In short, when designing a system, we need to use abstraction for analysis, instead of the division or details of classification classes at the beginning.

Definition 2:"Do not implement programming for the interface."[2]

In short, we can use interfaces and abstract classes to declare variables, parameters, methods, and so on. In addition, the implementation class is prohibited from making the above declarations.

To sum up, we can understand the principle of dependency switching as something in real life. For example, pregnant women and Longfeng children.

Only pregnant women can produce dragon and Phoenix. Pregnant women are abstract, and longfengtai (including baby boys and baby girls) is realized. Shows the specific class diagram:

Http://hi.csdn.net/attachment/201111/1/0_13201170861avv.gif

Fig 5.1

5.2 why dependency Switching

We can analyze the dependency switching principles from the following two points:

I. Reasons for switching:

Currently, In order to reuse code During the software project development process. We often write some common functions and functions as common modules to facilitate calls by developers.

If our general-purpose modules are not properly designed, they cannot be used. For example, we encapsulate Oracle code in the type conversion function class, while SQL Server is used in our new project. At this time, an error will inevitably occur when calling this common module. To solve this problem, we must refactor the Code. In this case, the reverse dependency is useful. By defining the conversion methods for Oracle, SQL Server, and other databases in the interface, we can implement the interface methods in the specific implementation class of SQL Server. In this way, no need to modify or add code to common modules whether new projects use Oracle or other databases in the future.

Ii. Functions of dependency interfaces:

As a complete abstract description interface, we can understand its function through a common instance.

For example, a telecom iptv TV box that connects to a user's home through a network through interlace. If the network connection of the IPTV machine room is changed, they only need to change in the machine room, and our iptv TV box still uses the original plug-in. If the TV box is not used through the plug-in, but directly connected to the TV station, the line may need to be modified when the network mode changes, and security risks are increased.

It can be seen that the interface greatly improves the scalability and flexibility of the system.

5.3 how to implement dependency Switching

How to Use the dependency switching principle is a subject worth pondering.

We may consider the following aspects:

1. analyze implementation classes and abstract classes. When using specific implementation classes to inherit abstract classes, we must ensure that the reference of 'base class' can be modified to its subclass.

2. Analyze the hierarchy. We need to define clear hierarchies so that each hierarchies can be implemented through interfaces.

3. analysis from the perspective of Object Construction. If a dynamic object is created, the dependency is replaced. If some static classes are created and the change rate is very low, we do not need to create a base class to inherit them to avoid the risk of maintaining unnecessary code.

To sum up, when using the dependency switching principle, we need to fully understand the definition and use the concept of hierarchy to call interfaces or abstract classes through specific implementation classes, finally, it achieves efficient, clear, and flexible system expansion.

5.4 application reflection

A small foreign trade company was just founded. In order to carry out B2C business needs to carry out website development, the company's boss commissioned me to help recruit two general Java programmers with one or two years of development experience. At this time, I have designed some questions. One employee management module is used as the design question. The details are as follows:

The company's staff includes the management and sales staff. Now, two Java programmers are recruited for business needs. (Please design the company staff management based on the dependency switching principle. You only need to create a Java class diagram and a brief code .)

There are two primary answers to the written test programmers:

I. Answers in violation of the dependency Switching Principle

Design three categories, each of which is created by the management, sales, and programmers.

Http://hi.csdn.net/attachment/201111/1/0_1320117116qr2G.gif

Fig 5.2

That is, the source code is:

Program 5.4.1

 

(1) Management

ImportJava. util. List;

ImportJava. util. Map;

Public classEmployee {

Public voidEmployee (){

} // Employee Interface

Public intSelectcount (string SQL, object entity ){

Return0;

}

// Insert data

PublicObject insert (string SQL, object entity ){

Return null;

}

// Modify data

PublicObject Update (string SQL, object entity ){

Return null;

}

// Delete data

PublicObject Delete (string SQL, object entity ){

Return null;

}

// Joint Query Method

PublicList selectunite (string SQL, map ){

Return null;

}

}

 

(2) salesman

ImportJava. util. List;

ImportJava. util. Map;

Public classSalesman {

Public voidSalesman () {// salesman class

}

PublicObject Delete (string SQL, object entity ){

Return null;

}

PublicObject insert (string SQL, object entity ){

Return null;

}

Public intSelectcount (string SQL, object entity ){

Return0;

}

PublicList selectunite (string SQL, map ){

Return null;

}

PublicObject Update (string SQL, object entity ){

Return null;

}

}

 

(3) programmers

ImportJava. util. List;

ImportJava. util. Map;

Public classProgrammer {// programmer

Public voidProgrammer (){

}

PublicObject Delete (string SQL, object entity ){

Return null;

}

PublicObject insert (string SQL, object entity ){

Return null;

}

Public intSelectcount (string SQL, object entity ){

Return0;

}

PublicList selectunite (string SQL, map ){

Return null;

}

PublicObject Update (string SQL, object entity ){

Return null;

}

}

 

2. Answers that comply with the dependency switching principle:

Http://hi.csdn.net/attachment/201111/1/0_1320117131JJBo.gif

Fig 5.3

Define employee interfaces, sales personnel, and programmers.

That is, the source code is:

Program 5.4.2

 

(1) Management

ImportJava. util. List;

ImportJava. util. Map;

Public interfaceIemployee {

Public voidIemployee (); // employee Interface

Public intSelectcount (string SQL, object entity );

// Insert data

PublicObject insert (string SQL, object entity );

// Modify data

PublicObject Update (string SQL, object entity );

// Delete data

PublicObject Delete (string SQL, object entity );

// Joint Query Method

PublicList selectunite (string SQL, map );

}

 

(2) salesman

ImportJava. util. List;

ImportJava. util. Map;

Public classSalesmanImplementsIemployee {// salesman implementation class

Public voidIemployee (){

}

PublicObject Delete (string SQL, object entity ){

Return null;

}

PublicObject insert (string SQL, object entity ){

Return null;

}

Public intSelectcount (string SQL, object entity ){

Return0;

}

PublicList selectunite (string SQL, map ){

Return null;

}

PublicObject Update (string SQL, object entity ){

Return null;

}

}

 

(3) programmers

ImportJava. util. List;

ImportJava. util. Map;

Public classProgrammerImplementsIemployee {// programmer implementation class

Public voidIemployee (){

}

PublicObject Delete (string SQL, object entity ){

Return NULL;

}

PublicObject insert (string SQL, object entity ){

Return null;

}

Public intSelectcount (string SQL, object entity ){

Return0;

}

PublicList selectunite (string SQL, map ){

Return null;

}

PublicObject Update (string SQL, object entity ){

Return null;

}

}

 

Iii. Comparison of the two answers

In response to the dependency switching principle, three classes are created: management, salesman, and programmer. If the three classes Add the same method, three classes need to be modified. In response to the dependency switching principle, you only need to add a method to the employee interface. In contrast, answers that comply with the dependency switching principle are more in line with the needs of software development. As a result, I eventually hired a programmer who answered based on the dependency switching principle.

5.5 References

[1] Robert C. Martin <Agile Software Development: Principles, models, and Practices> 116th

[2] Development Macro <Java and mode> 87th page

 

Jiang haichang, a blogger who once published design patterns, demand analysis, and project management articles in academic journals, is entitled to copyright to this blog article. For Network reprint, please indicate the source: http://blog.csdn.net/alike188/article/details/6924.pdf. To organize the publications, contact the author. If you have any suggestions or comments, please refer to the comments! QQ: 2337605394, Java design mode group
12999329