Back to the homepage

Angular & Interface Segregation Principle


This is the fourth article in the series on the acronym SOLID. It is a set of rules thanks to which we can write code that will be easier for us to scale, and change the behavior of our application, without moving the code of a large part of the app.

The set of rules consists of:

Today we will be dealing with the Interface Segregation Principle 🙂

Interface Segregation Principle


As you can see in the picture – customers should not be forced to rely on interfaces that they do not use. In other words, it’s better to have more but smaller interfaces than one large one.

What does this mean in practice?

Let’s look at an example. Let’s assume that in our application we have the following view:

This is a table with a list of users. It shows the name and status of the user. The model is implemented as follows:

The way our application works is that after double-clicking on the row it goes to the detail view:

There is much more information shown here, than those that are in the list view. Therefore, we could customize the model so that the same one is used for the list view as well as the details view (using optional fields):

However, this approach causes several problems. First of all, the model for the list view contains fields that do not physically appear there. Secondly, while having optional fields in many places in the application, may quickly lead to a situation where we do not know where a given field is always required and where it is not. Thirdly, in the case of a refactor (e.g. changing response from the server), we will not know which fields we can change or delete and which we cannot.

Therefore, it is better to create a separate model for the list view, and the detail view. Then we will avoid optional fields, and our components will have clearly defined ranges of knowledge about the models they support.

And for the details view:

In this way, we adhere to the Interface Segregation Principle.

Let’s look at another example. Let’s assume that we have an application for handling e-mails and users. It consists of 2 main views. The first is the admin view, where we can:

  • delete
  • add
  • update users.

This is a panel that is only visible to a small number of users. The second view is the view with the message filter. Here we can only download a list of users or details of a particular user. This view is used by most app users. Both views use the service to retrieve data from the server:

It is visible that the message filter panel uses only two methods – “getAll” and “getOne”. The others are unnecessary to it. Following the definition of “it is better to have more interfaces, but smaller ones”, we should separate sub-interfaces here. One, containing methods available for most users:

And the second, with actions requiring appropriate permissions:

Then, instead of using a specific implementation in both views, we should inject the created interfaces:

In this way, components have access only to the methods they use. Thanks to that, the Interface Segregation Principle is followed.

In the next article, we will focus on the last rule that makes up SOLID – Dependency Inversion Principle 🙂

About the author

Wojciech Janaszek

I am an Angular and NestJS developer. I started my adventure with the first versions of "new" Angular (2 and up). Recently I'm also using NestJS (which is easy to learn if you know Angular well - everything is very similar). In my work I pay a lot of attention to so called clean code and clean architecture. I like to have "order" in the code :) In my free time I am interested in sports cars, motorsport in general. I also play amateur volleyball.

Do you want to write articles for our blog together with us?
Join us and create valuable content for Angular fans with!

Leave a Reply

Your email address will not be published. Required fields are marked *