Introduction
This is a sincere attempt to make the audience understand the importance of Interface Segregation principal of SOLID, and how it can be useful and implemented.
Background
Couple of times, we see that we are bound to implement interfaces which are fat, what I mean is we have to implement the methods which we really don't need or would be of any help to us.
This coding tip explains how we can really identify a fat interface and refactor the code in order to make the interface thin without really breaking the application.
Using the Code
Let's do step by step refactoring to make the whole thing look simpler and easy to understand.
We have an interface called
IDataOperation
which is designed to perform lot many things.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
public interface IDataOperation
{
void saveData(string name);
bool connectDataBase();
void createReportData();
}
}
Now we have a concrete class called
ReportAccess
which implements
IDataOperation
.
You can see below that the class requires only
createreportData
method, but it had to implement all the irrelevant methods also:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
class ReportAccess :IDataOperation
{
#region IDataOperation Members
public void saveData(string name)
{
Console.WriteLine("Saving Data..");
}
public bool connectDataBase()
{
throw new NotImplementedException();
}
public void createReportData()
{
Console.WriteLine("Created report data...");
}
#endregion
}
}
Refactoring Begins .....
We can refactor the interface
IDataOperation
and separate the method
CreateDataReport
and place it into a new interface called
IReportOperation
.
After refactoring, the code will look like the below snippet:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
public interface IDataOperation
{
void saveData(string name);
bool connectDataBase();
void createReportData();
}
public interface IReportOperation
{
void createReportData();
}
}
In order to prevent the application from breaking, what we can do is derive
IDataOperation
from
IReportOperation
and code now would look like this ..
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
public interface IDataOperation : IReportOperation
{
void saveData(string name);
bool connectDataBase();
void createReportData();
}
public interface IReportOperation
{
void createReportData();
}
}
On the other hand, we can also use only the
IReportOperation
interface in the concrete class
ReportAccess
and get rid of irrelevant methods so after refactoring the class
ReportAccess
the code would look like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
class ReportAccess :IReportOperation
{
#region IDataOperation Members
public void createReportData()
{
Console.WriteLine("Created report data...");
}
#endregion
}
}
The commented out sections are the methods which no longer need to be implemented or bothered about:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace SOLID
{
class Program
{
static void Main(string[] args)
{
ReportAccess rp = new ReportAccess();
rp.createReportData();
}
}
}
Finally, we have our main method.