Introduction
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:
- Single Responsibility Principle,
- Open/Closed Principle,
- Liskov Substitution Principle,
- Interface Segregation Principle,
- Dependency Inversion Principle.
Today we will be dealing with the Interface Segregation Principle ?
Interface Segregation Principle
Credit: https://blog.larapulse.com/clean-code/solid-in-simple-words
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:
|
1 2 3 4 5 |
export type User = { id: UserId; name: string; status: UserStatus; } |
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):
|
1 2 3 4 5 6 7 8 |
export type User = { id: UserId; name: string; status: UserStatus; profilePhoto?: ResourceUrl; email?: string; roles?: UserRole[]; } |
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.
|
1 2 3 4 5 |
export type UserUiListItem = { id: UserId; name: string; status: UserStatus; } |
And for the details view:
|
1 2 3 4 5 |
export type UserUiDetail = UserUiListItem & { profilePhoto: ResourceUrl; email: string; roles: UserRole[]; } |
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:
|
1 2 3 4 5 6 7 |
export interface UserResource { create(user: User): Observable<void>; delete(id: EntityUid): Observable<void>; getAll(): Observable<User[]>; getOne(id: EntityUid): Observable<User | undefined>; update(user: User): Observable<void>; } |
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:
|
1 2 3 4 |
export interface StandardUserResource { getAll(): Observable<User[]>; getOne(id: EntityUid): Observable<User | undefined>; } |
And the second, with actions requiring appropriate permissions:
|
1 2 3 4 5 |
export interface PrivilagedUserResource { create(user: User): Observable<void>; delete(id: EntityUid): Observable<void>; update(user: User): Observable<void>; } |
Then, instead of using a specific implementation in both views, we should inject the created interfaces:
|
1 2 3 4 5 6 |
@Component() export class MessageFilterComponent { constructor( @Inject(STANDARD_USER_RESOURCE) private standardUserResource: StandardUserResource ) {} } |
|
1 2 3 4 5 6 7 |
@Component() export class AdminComponent { constructor( @Inject(PRIVILAGED_USER_RESOURCE) private privilagedUserResource: PrivilagedUserResource, @Inject(STANDARD_USER_RESOURCE) private standardUserResource: StandardUserResource ) {} } |
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 ?
Leave a Reply