SOLID Principles : Guidelines for software development :: DIP
The SOLID principles provide five guidelines that, when followed, can dramatically enhance the maintainability of software.
| Dependency Inversion Principle Intro |
The DIP states that high level modules should not depend upon low level modules and that abstractions should not depend upon details.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:
High Level Classes ==> Abstraction Layer ==> Low Level Classes
Intent
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
The Principle
The Dependency Inversion Principle (DIP) states that high level modules should not depend upon low level modules. Both should depend upon abstractions.
Secondly, abstractions should not depend upon details. Details should depend upon abstractions.
The idea of high level and low level modules categorises classes in a hierarchical manner.
- High level modules or classes are those that deal with larger sets of functionality.
- At the highest level they are the classes that implement business rules within the overall design of a solution. Low level modules deal with more detailed operations.
- At the lowest level they may deal with writing information to databases or passing messages to the operating system. Of course, there are many levels between the highest and the lowest. The DIP applies to any area where dependencies between classes exist.
The DIP can be described more easily with an example. Consider a banking solution.
- As a part of the software it is necessary to transfer money between accounts. This may involve a class for a bank account with an account number and a balance value.
- It may include methods that add or remove funds from the account.
- To control transfers between accounts you may create a higher level TransferManager class.
- This may have properties for the two accounts involved in the transaction and for the value of the transfer.
A possible design is shown below:
Another Example
In the above figure, Dependency Inversion Principle not applied
- The problem with such a design is that the high level TransferManager class is directly dependent upon the lower level BankAccount class. The Source and Destination properties reference the BankAccount type. This makes it impossible to substitute other account types unless they are subclasses of BankAccount. If we later want to add the ability to transfer money from a bank account to pay bills, the BillAccount class would have to inherit from BankAccount.
- As bills would not support the removal of funds, this is likely to break the rules of the Liskov Substitution Principle (LSP) or require changes to the TransferManager class that do not comply with the Open / Closed Principle (OCP).
Further problems arise should changes be required to low level modules.
A change in the BankAccount class may break the TransferManager. In more complex scenarios, changes to low level classes can cause problems that cascade upwards through the hierarchy of modules. As the software grows, this structural problem can be compounded and the software can become fragile or rigid.
Applying the DIP resolves these problems by removing direct dependencies between classes.
Instead, higher level classes refer to their dependencies using abstractions, such as interfaces or abstract classes. The lower level classes implement the interfaces, or inherit from the abstract classes. This allows new dependencies to be substituted without impact.
Furthermore, changes to lower levels should not cascade upwards as long as they do not involve changing the abstraction.
The effect of the DIP is that classes are loosely coupled. This increases the robustness of the software and improves flexibility. The separation of high level classes from their dependencies raises the possibility of reuse of these larger areas of functionality.
Without the DIP, only the lowest level classes may be easily reusable.
Another Example
Download Examples
Code Available Before DIP
BankAccount.java
package com.javaskool.before;
public class BankAccount {
public String AccountNumber;// { accessor; mutator; }
public double Balance;// { accessor; mutator; }
public void AddFunds(double value)
{
Balance += value;
}
public void RemoveFunds(double value)
{
Balance -= value;
}
}TransferManager.java
package com.javaskool.before;
public class TransferManager
{
public BankAccount Source;// { accessor; mutator; }
public BankAccount Destination;// { accessor; mutator; }
public double Value;// { accessor; mutator; }
public void Transfer()
{
Source.RemoveFunds(Value);
Destination.AddFunds(Value);
}
}Code Available After DIP
ITransferSource.java
package com.javaskool.after;
public interface ITransferSource {
void RemoveFunds(double value);
}ITransferDestination.java
package com.javaskool.after;
public interface ITransferDestination {
void AddFunds(double value);
}BankAccount.java
package com.javaskool.after;
public class BankAccount implements ITransferDestination, ITransferSource
{
public String AccountNumber;// { accessor; mutator; }
public double Balance;// { accessor; mutator; }
public void AddFunds(double value)
{
Balance += value;
}
public void RemoveFunds(double value)
{
Balance -= value;
}
}TransferManager.java
package com.javaskool.after;
public class TransferManager
{
public ITransferSource Source;// { accessor; mutator; }
public ITransferDestination Destination;// { accessor; mutator; }
public double Value;// { accessor; mutator; }
public void Transfer()
{
Source.RemoveFunds(Value);
Destination.AddFunds(Value);
}
}
Recent Comments