Introduction to Interface Driven Development (IDD)

1. Overview

In this tutorial, we’ll discuss Interface Driven Development (IDD), which provides structure to coding. We’ll guide you through the usage of IDD and explain its benefits.

2. Idea

Interface Driven Development is a development approach that focuses on the design of interfaces between different components of a system. The respective interfaces define the usable methods. Thus, we provide information on the available functionality, expected parameters, and return value.

2.1. Advantages

Since IDD defines the interface at the beginning, projects with several employees can simultaneously begin using it and developing its implementation. This speeds up development because they can write code before the implementation is ready.

In addition, the coupling between individual modules becomes looser, resulting in a more flexible and robust system. Individual interfaces can then have one or more implementations. Other modules can directly instantiate these or inject them using annotations. If there are multiple possible implementations when using Spring Boot, @Qualifier annotation helps select the correct implementation.

For example, there could be an interface that defines the following method:

HelpRequest getHelpRequestById(Long id);

Two services can implement this interface, one accessing a cache and the other accessing a database to return the desired object. The class that uses the interface is indifferent to the implementation and can exchange them flexibly depending on the requirements. This leads to better maintainability because the class that uses the interface doesn’t need to worry about the implementation details as long as the contract defined in the interface is upheld.

The approach is somewhat similar to Test Driven Development, where tests are first defined, and then a matching implementation is made until the test runs successfully. The IDD approach also delivers significant benefits in testing.

The interface makes it possible to mock the individual methods easily without having to mock the class via a mocking framework. This allows each component of the system to be tested in isolation. Since Java 15, it is also possible to use Sealed Interfaces to specify which classes are allowed to implement the interface. This provides additional protection.

3. Example

Below, we look at how to proceed with IDD using a concrete example. For example, let’s take an app called ‘Machbarschaft’, which helps neighbors connect and make requests for help, such as help with shopping or household chores.

In the context of IDD, the app’s development would proceed as follows.

3.1. Identification of Interfaces

We first identify different app modules such as notifications, help requests, or user management. In this article, we’ll focus on help requests.

3.2. Determining the Use Cases

Now we look out for possible use cases for all modules. For example, for the help requests module, this could be to create a help request, complete or edit a help request and retrieve all help requests with a certain status.

3.3. Defining the Interface

Considering these use cases, the interface for the HelpRequestService could look like this:

public interface HelpRequestService {
    HelpRequestDTO createHelpRequest(CreateHelpRequestDTO createHelpRequestDTO);

    List<HelpRequestDTO> findAllByStatus(HelpRequestStatus status);

    HelpRequestDTO updateHelpRequest(UpdateHelpRequestDTO updateHelpRequestDTO);
}

The createHelpRequest method takes a CreateHelpRequestDTO with information about creating the help request and returns the created help request mapped to a HelpRequestDTO.

The findAllByStatus method takes only HelpRequestStatus, for example, OPEN to only return a List of all HelpRequestDTO which fit the criteria. This allows the developer to pick only help requests which should be done by a user or show all help requests which are currently being worked on.

The last method is there for updating a help request. Here the method gets passed the updated information and then returns the updated help request mapped into the HelpRequestDTO.

3.4. Independent Development of Modules

Developers can develop the modules independently by default. Each module here would rely on the interfaces of other modules to perform its functions. This is what an implementation would look like:

public class HelpRequestServiceImpl implements HelpRequestService {

    @Override
    public HelpRequestDTO createHelpRequest(CreateHelpRequestDTO createHelpRequestDTO) {
        // here goes the implementation 
        return new HelpRequestDTO();
    }

    @Override
    public List<HelpRequestDTO> findAllByStatus(HelpRequestStatus status) {
        // here goes the implementation
        return List.of(new HelpRequestDTO());
    }

    @Override
    public HelpRequestDTO updateHelpRequest(UpdateHelpRequestDTO updateHelpRequestDTO) {
        // here goes the implementation
        return new HelpRequestDTO();
    }
}

There could also be an asynchronous version of the HelpRequestServiceImpl or, as earlier mentioned, one version that uses a cache and the other user access to a database.

3.5. Testing of the Implementation

Now that the interface has been successfully implemented, we can move on to testing it extensively to ensure that the code works as desired. In the case of the findAllByStatus method, we could check if the method only contains objects with the correct status:

@Test
void givenHelpRequestList_whenFindAllByStatus_shouldContainOnlyStatus(){
    HelpRequestService helpRequestService = new HelpRequestServiceImpl();
    List<HelpRequestDTO> allByStatusOpen = helpRequestService.findAllByStatus(HelpRequestStatus.OPEN);
    Assertions.assertThat(allByStatusOpen).extracting(HelpRequestDTO::getStatus)
      .containsOnly(HelpRequestStatus.OPEN);
}

3.6. Integration of Modules

After developing and testing each module, the team integrates them by communicating with one another through their defined interfaces. This would allow for easy integration and low coupling between the different modules:

HelpRequestService helpRequestService = new HelpRequestServiceImpl();
helpRequestService.findAllByStatus(HelpRequestStatus.OPEN);

By using IDD, developing the “Machbarschaft” app becomes easier and more robust. The clear definition of interfaces and independent development of modules facilitates testing and integration, while the low coupling between modules enables fast and secure maintenance and extension.

Overall, IDD helps to develop a high-quality and user-friendly app that meets the needs of the users.

4. Conclusion

In this article, we discussed the advantages of IDD and showed a concrete example of how to use IDD. Overall, IDD can help reduce the complexity of a system, improve maintainability and extensibility, and reduce development time and costs.

As always, the example code is available over on GitHub.