Do you code against interfaces?

Last updated by Brady Stroud [SSW] 15 days ago.See history

Appropriate use of design patterns can ensure your code is maintainable and easy to read.

Code against Interfaces

Always code against an interface rather than a concrete implementation. Use dependency injection to control which implementation the interface uses. By doing this you create a contract for that service which the rest of the codebase has to adhere to.

By creating an interface for each service and programming against the interface, you can easily swap out the implementation of the service without changing the code that uses the service.

It is important to also control the scope of the injection. For example, in ASP.NET 8 application you have the option to register the concrete implementation in the DI container either as a singleton, scoped, or transient service. Each of them will have a different lifetime in the application and should be set as per the requirement.

Code against interfaces   bad ❌ Figure: Bad Example - Referencing the concrete EF context

This is bad code because now the controller is directly dependent on the implementation of the EF context. This also increase the effort for unit testing.

Code against interfaces   good ✅ Figure: Good Example - Programming against the interface

This is good because now you can test the controller and the services independently. Also the controller only talks to the service through the functionality exposed by the interface, enforcing encapsulation.

We open source. Powered by GitHub