Design principles (iv) Dependency inversion principle (DIP) __java

First, what is the dependency inversion principle

A statement:
Abstraction should not depend on detail; the details should depend on abstraction.

Another statement:
To program for an interface, do not program for implementation.

Programming for interfaces means that you should use Java interfaces and abstract Java classes for variable type declarations, parameter type declarations, return type declarations of methods, and conversion of data types.

Do not aim at implementing programming means that you should not use specific Java classes for variable type declarations, parameter type declarations, method return type declarations, and data type conversions.

Second, why to invert

The traditional design method of the process system tends to make the high-level module depend on the low-level module, and the abstraction level depends on the concrete level. The inverted principle is to reverse the wrong dependency.

The abstract level contains the business logic of the application and the macro-strategic decisions that are important to the system as a whole, while the concrete level contains some minor algorithms and logic for implementation, as well as tactical decisions, with considerable contingency choices. Code at a specific level often changes and cannot avoid errors. The abstraction level relies on the concrete level, causes many concrete level details the algorithm change to immediately affect the abstract level macroscopic business logic, the inverted microcosmic decision macroscopic, the tactical decision strategy, the accidental decision inevitable, this is not very absurd.

Third, look at the factory method mode again

Depending on the dependency inversion principle, the client should rely on the abstract type of the object rather than its specific type, but the constructor of the concrete class must be invoked when creating a concrete object instance using new in Java, so instances of the class given by the Java language cannot be relied upon only on abstract types. But we can do it partly because there are polymorphic features in Java. For example, a is an abstract class, B is a specific subclass that inherits from a, and we can write the following code:

b b = new B ();

This is a completely dependent on the specific bad writing, we can use polymorphism to write the following:

A A = new B ();

This becomes partial dependency, and the front of a is dependent on abstraction, so that other programs will not be affected when B is replaced by other subclasses that inherit from a. Even if this is not entirely dependent on abstraction, the factory method pattern discussed in the design pattern solves the problem.

The factory method pattern encapsulates the project that creates an object, the client only gets the result of the instantiation, and the abstract type of the instance, and of course the factory method does not avoid the restriction of creating objects with new, but the factory model defers the rule-breaking practice to the specific factory role. Isolate the rule-breaking approach in a place that is easy to control.

Iv. Example Analysis

This is an example of a bank account, with two parts, AccountType and Accountstatus, of which two classes are abstract, and the two classes have two specific subclasses, and accounts use abstract classes instead of subclasses. This is consistent with the dependency inversion principle in account.

Package Com.designphilsophy.dip;
/** * * @author xingjiarong * * * * * * * * * * Public
 class account
{

    private accounttype accounttype;
    Private Accountstatus accountstatus;

    Public account (AccountType accttype) {
        //write your code here
    } public

    void deposit (Float amt) {
        //WR Ite your code here
    }

}

Package Com.designphilsophy.dip;

/** * The status of the
 account is open or overrun status
 * @author xingjiarong
 * */Public
abstract class Accountstatus
{
    public abstract void Sendcorrespondence ();
}

Package Com.designphilsophy.dip;

/**
 * The type of account is card or cheque
 * * * 
 @author Xingjiarong * */public
abstract class AccountType { Public
    abstract void deposit (float amt);
}

Package Com.designphilsophy.dip;

/** * *
 @author xingjiarong * */public
class Checking extends AccountType {
    public void deposit (float amt) {
        //write your code here
    }
}

Package Com.designphilsophy.dip;

/**
 * Card * * * @author xingjiarong * */public
class Savings extends AccountType {
    public void deposit (float amt) {
        //write your code here
    }
}

Package Com.designphilsophy.dip;

/** * *
 @author xingjiarong * */public
class Open extends Accountstatus {
    public void Sendcorrespondence () {
        //write your code here
    }
}

In this example, the account class relies on AccountType and accountstatus, but these two classes are abstract, and if we want to add a new state overrun state, it will not affect other classes.

Package Com.designphilsophy.dip;

/**
 * Overrun Status
 * @author xingjiarong
 */public
class Overdrawn extends Accountstatus {
    public void Sendcorrespondence () {
        //write your code here
    }
}

SOURCE Download: http://download.csdn.net/detail/xingjiarong/9309387