An Opinionated Usage of Interface
Every C# developer knows what interface is. From the code perspective it is interface ISomething. There is no requirement for the I in the interface name. But that is just the naming convention. And it is good to know it is an interface by looking at the name. A more interesting question is when do we use interface?. And I guess each developer might have their own answer and reasons behind them.
Back in time, about 10 years ago, I started to use interface a lot. Back then the obvious reason was mocking and unit testing. And then the dependency injection came to my developer life. I read somewhere that you should inject interfaces instead of concrete implementations.
Have you ever heard of these?
- Depend on interfaces instead of concrete implementations
- It is easier for you to change the implementation later
- It helps you mocked the implementation in the unit test
- Your code looks clean and professional
- …
In some codebases, I ended up with interfaces everywhere. The unit test was a bunch of mocks and mocks, everywhere. It looked good in the beginning. However, after a while, it was a pain.
- It was hard to do the refactoring. For example, when I did not want to move a piece of code from this class to another class without changing the outcome behavior, the unit test failed. Because the expected interface was no longer there. The unit test knew too much about the implementation detail. I have the habit of refactoring code quite often. And I expect the unit test to catch my mistake if I accidentally change the outcome behavior. With mocking, I failed to archive that
- Had to test at every layer. Basically, there were behavior test with mocking and there were tests for actual implementation. There were too much test code to maintain. Well, that was a waste of time and effort and error prone in the test
- The chances of actually changing an implementation was rare
Ok, so is interface useful? Of course yes it is. And here are my opinions when to use it.
Code Contract
The interface tells the consumers the functionalities it supports. A class might have 10 methods. But not all consumers use or care 10 methods. They might be interested in 2 or 3 methods. It is fine to inject the class. However, the consumer is confused and might misuse.
Let take an example of an imagination log service. Here is the concrete implementation
public class SimpleLogService
{
public void WriteLog(string logMessage)
{
}
public IList<string> GetLogs()
{
return new List<string>();
}
}
// API Controller to read the log
public class LogController : Controller
{
private readonly SimpleLogService _logService;
public LogController(SimpleLogService logService)
{
_logService = logService;
}
public IActionResult Get()
{
return OK(_logService.GetLogs());
}
}There is nothing wrong with the above code. However, I do not want the LogController to see/use the WriteLog method. That method is used by another controllers or services. And the SimpleLogService class might grow in size over the time. More and more methods are developed.
To solve that problem, I want to create a contract to tell LogController what it can use.
public interface ILogReaderService
{
public IList<string> GetLogs();
}
public class SimpleLogService : ILogReaderService
{
public void WriteLog(string logMessage)
{
}
public IList<string> GetLogs()
{
return new List<string>();
}
}
// API Controller to read the log
public class LogController : Controller
{
private readonly ILogReaderService _logService;
public LogController(ILogReaderService logService)
{
_logService = logService;
}
public IActionResult Get()
{
return OK(_logService.GetLogs());
}
}And I can do the same for the WriteLog part if necessary.
Decouple Implementation Dependency
In many projects, there is data involve. There are databases. And then comes the concept of Repository. And if the repository implementation is easy and that the database is ready. A developer can write a complete feature from API layer down to database layer. But I am doubt that is the reality. So the situation might look like this
- One developer takes care of front end development
- One developer takes care of the API (controller) implementation
- One developer takes care of designing database, writing the repository. This might be the same developer that implements the API
The API layer depends on the Repository. However, we also want to see the flow and speed up the development. Let’s see some code
public class UserController : Controller
{
private readonly IUserRepository _repository;
public UserController(IUserRepository repository)
{
_repository = repository;
}
public async Task<IActionResult> GetUsers()
{
var users = await _repository.GetAllUsers();
return Ok(user);
}
}The IUserRepository is the Code Contract between API and the repository implementation. To unlock the development flow, a simple in memory repository implementation is introduced
public class InMemoryUserRepository : IUserRepository
{
public async Task<IList<User>> GetAllUsers()
{
await Task.CompletedTask();
return new List<User>{
new User("Elsa"),
new User("John"),
new User("Anna")
};
}
}And the API can function. This releases the dependency on the actual repository implementation. When such an implementation is ready, switch to use it.
However, do not overuse it. Otherwise, you end up with interfaces everywhere and each developer gives their own temporary implementations. Choosing the right dependencies is an art and context matters a lot.
Conclusion
I rarely create interfaces with the purpose of unit testing in mind. Rather, it is the outcome of writing code, refactoring from a concrete implementation and then extracting into interfaces where they make the most sense. When I do, I pay close attention to its meaning. If I can avoid an interface, I will do it.
Code Contract and Decouple Implementation Dependency are the 2 big benefits from having proper interfaces. There are other reasons to use interfaces. They are all valid depending on the context. Sometime, it is the way the project architect wants it.
What are yours?
