SOLID - Dependency Inversion - Principle

Usually you instantiate dependencies of a class inside that class. In the process, the class becomes tightly coupled with its dependencies. Any change in the dependency may require a change in the class. The root cause of this tight coupling is that the class creates its own dependencies. To loosen this coupling, dependencies can be supplied to a class from the external world. That’s where the Dependency Inversion Principle comes into the picture. The DIP can be stated as the following

A. High-level classes should not dependent on low-level classes. Both of them should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

Assumptions
Assuming we had completed the Interface Segregation example in our SOLID Principle. We may now trying to make an example of Dependency Inversion

The Requirement
There is a requirement stated that we need to log all the message that being sent from all micro services.

The Code - IMicroServicesLogger
First we create an interface

	namespace LiskovHarryKanePenalty.IMicroMessage
	{
	public interface IMicroServicesLogger
	{
	void LogMessage();
	}
	}

view raw IMicroServicesLogger.cs hosted with ❤ by GitHub

Next Create Dependency Inversion In Client Classes
In this case we will make use of InternalMessageChannel and ExternalMessageChannel to demonstrate Dependency Inversion. In the code snippet below, we first insert a constructor to accept the IMicroServicesLogger. We also leave the default constructor just in case there is no need for logging during development phase. Next we perform the Logging during the specific action method.

	namespace LiskovHarryKanePenalty.IMicroMessage
	{
	public class ExternalMessageChannel : IMicromessage , IProtectedMessage
	{
	public IMicroServicesLogger _Logger { get; set; }
	private string _Message;
	public ExternalMessageChannel(IMicroServicesLogger logger)
	{
	this._Logger = logger;
	}
	public ExternalMessageChannel()
	{
	this._Logger = new DefaultLogger();
	}
	public string SendData()
	{
	this._Logger.LogMessage();
	return _Message;
	}
	public void ProtectData()
	{
	this._Message = Encryption.ProtectMicroservices(this._Message);
	}
	}
	}

view raw ExternalMessageChannelInversion.cs hosted with ❤ by GitHub

The Implementation Of Logger
Next we may implement it on a logger, Assuming we have a specific logging mechanism for Accounting Module, we may then implement the interface something like this.

	namespace LiskovHarryKanePenalty.IMicroMessage
	{
	public class AccountingModuleLogger : IMicroServicesLogger
	{
	public void LogMessage()
	{
	/// Log Message
	}
	}
	}

view raw AccountingModuleLogger.cs hosted with ❤ by GitHub

The Client Implementation
Next we may make use of the logger with Dependency Inversion Technique.

	namespace LiskovHarryKanePenalty.IMicroMessage
	{
	public static class UsageExample
	{
	public static void DoExample()
	{
	// Assuming We have Accounting Module Specific Logger
	AccountingModuleLogger logAcc = new AccountingModuleLogger();
	ExternalMessageChannel msg = new ExternalMessageChannel(logAcc);
	// Process message
	MicroHttpService svc = new MicroHttpService();
	var data = svc.ClassSendData(msg);
	}
	}
	}

view raw DInversionExample.cs hosted with ❤ by GitHub

Conclusion
From the article, we may understand how to perform SOLID in our design patterns. It is important to understand how Dependency Inversion really help us in designing a maintainable/readable software codes.

Published on : 10-Jan-2019
Ref no : DTC-WPUB-000105

About Author

Wan Mohd Adzha CAPM,MCPD,MCSD,MCSE
Passionate about new technology ( Software Engineering ) and how to build,manage and maintain them