Understanding the dependency injection pattern – Angular Services and the Singleton Pattern

In object-oriented software development, it is good practice to prioritize composition over inheritance, meaning that a class should be composed of other classes (preferably interfaces).
In our previous example, we can see that the service class comprises the DiaryComponent component. Another way to use this service would be as follows:

.
.
.
export class DiaryComponent {
private exerciseSetsService: ExerciseSetsService;
exerciseList: ExerciseSetList;
constructor() {
this.exerciseSetsService = new ExerciseSetsService();
this.exerciseList = this.exerciseSetsService.getInitialList();
}
.
.
.
}

Here we modify our code, leaving the creation of the service class object expressly in the component’s constructor method. Running our code again, we can see that the interface remains the same.
This approach, although functional, has some problems, such as the following:
• High coupling between the component and the service, which means that we may encounter problems if we need to change the implementation of the service, for example, for the construction of unit tests
• If the service depends on another class, as we will see with Angular’s HTTP request service, the HttpClient class, we will have to implement this dependency in our component, increasing its complexity
To simplify development and solve the problems we’ve described, Angular has a dependency injection mechanism. This feature allows us to compose a class just by declaring the object we need in its constructor.
Angular, leveraging TypeScript, will use the types defined in this declaration to assemble the dependency tree of the class we need and create the object we require.
Let’s return to our code and analyze how this mechanism works:

.
.
.
export class DiaryComponent {
constructor(private exerciseSetsService: ExerciseSetsService) {}
exerciseList = this.exerciseSetsService.getInitialList();
.
.
.
}

In the code, we declare the dependency of our class in the constructor, creating the exerciseSetsService attribute. With this, we can initialize the exerciseList attribute in its declaration.
In Chapter 10, Design for Tests: Best Practices, we will replace the implementation of this service in the test runtime. All this is possible thanks to Angular’s dependency injection feature.
From version 14 of Angular, we have an alternative for dependency injection that we can use, which we will see next.