Dependency Inversion Principle
If you are following the Software Design Principles while developing an application, the first thing that comes to your mind is the Dependency Inversion Principle.
"High level modules should not depend upon low level modules, rather both should depend upon abstractions"
The line means, that the modules should put dependencies in form of abstractions rather than concrete class dependencies. Consider the example below :
public class Customer
{
public string Name {get;set;}
public void GetCustmerName()
{
try
{
return this.Name;
}
catch (Exception e)
{
FileLogger f = new FileLogger();
f.LogError(e);
}
}
}
public class FileLogger
{
public void LogError(Exception e)
{
//Log Error in a physical file
}
}
The above code has a problem. The Customer class is directly dependent on FileLogger type. The FileLogger and the Customer is tightly coupled and think if they belong to separate libraries, that means they are inseparable from one another.
Following Dependency Inversion principle, one should use an Interface to provide dependency, such that the concrete implementation could be separated form one another.
public class Customer
{
public string Name {get;set;}
public ILogger Logger { get;set;}
public void GetCustmerName()
{
try
{
return this.Name;
}
catch (Exception e)
{
this.Logger.LogError(e);
}
}
}
public interface ILogger
{
void LogError(Exception e);
}
public class FileLogger:ILogger
{
public void LogError(Exception e)
{
//Log Error in a physical file
}
}
public class EventViewerLogger : ILogger
{
public void LogError(Exception e)
{
//Log Error in a physical file
}
}
Here the Customer class is not totally dependent with the concrete class FileLogger, rather it is dependent using an interface ILogger.