SOLID is a mnemonic proposed by Robert C. Martin. Known in the programming community as Uncle Bob. SOLID principles constitute a key set of guidelines in object-oriented programming (OOP), focusing on promoting clean, modular, and maintainable code. The name Solid consists of the first letters of the five principles:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

(SRP) Single Responsibility Principle

The principle was first formulated by Tom DeMarco and Meilir Page-Jones under the name of the principle of cohesion, and it was popularized and presented in its current form by Robert C. Martin in the article “Principles of Object Oriented Design” and the book “Agile Software Development: Principles, Patterns, and Practices”.

The principle proclaim that there should never be more than one reason for a class, method or function to exist.

The easiest way to explain this is with an example. If we want to display a list of categories and the products belonging to a selected category, we should not create a single component containing both the category list and the products of that category.

Components with a single, reusable functionality should be implemented. This means that the data filtering functionality should be broken down into multiple components. In our case, we create a component that contains the functionality for displaying a dropdown list. Another component should handle the functionality of displaying products by category. Additionally, services for categories and products need to be created. These services will be responsible for displaying the data. The services should communicate with each other to pass information about which object the data should be filtered based on.

Below is the component for selecting the category by which the products are filtered:

import { JsonPipe, NgFor } from '@angular/common';
import { Component, inject, input, signal } from '@angular/core';
import { MatFormFieldModule } from '@angular/material/form-field';
import { MatSelectChange, MatSelectModule } from '@angular/material/select';
import { CategoriesService } from '../../services/categories.service';

@Component({
  selector: 'app-select',
  standalone: true,
  imports: [JsonPipe, MatFormFieldModule, MatSelectModule, NgFor],
  template: `
  <mat-form-field>
    <mat-label>{{label()}} </mat-label>
    <mat-select [value]="selected()" (selectionChange)="onSelectedCategoryChange($event)">
        <mat-option>None</mat-option>
        @for (item of list(); track item ) {
          <mat-option [value]="item">{{ item.name }}</mat-option>
        }
    </mat-select>
  </mat-form-field>  
  `,
  styleUrl: './select.component.scss'
})
export class SelectComponent {
  private categoriesService = inject(CategoriesService);

  label = input('')
  list = input<any[]>([]);
  selected = signal<any>({});

  onSelectedCategoryChange(event: MatSelectChange) {

    this.selected.update(val => val = event.value);
    this.categoriesService.setSelectedCategory(this.selected())
  }
}

Below is the component for the functionality of filtering the product list by category:

import { Component, Signal, inject } from '@angular/core';
import { MatListModule } from '@angular/material/list';
import { ProductsService } from '../../services/products.service';
import { Product } from '../../models/models';

@Component({
  selector: 'app-products-list',
  standalone: true,
  imports: [MatListModule],
  template: `
  <mat-list>
    @for (product of listProducts(); track product.id ) {
        <mat-list-item>{{ product.name }}</mat-list-item>
    }
  </mat-list>
  `,
  styleUrl: './products-list.component.scss',
})
export class ProductsListComponent {
  listProducts: Signal<Product[]> = inject(ProductsService).getProducts();
}

Product service:

import { Injectable, Signal, signal } from '@angular/core';
import { Product } from '../models/models';


@Injectable({
  providedIn: 'root'
})
export class ProductsService {

  listProducts: Product[] = [
    { id: 1, name: 'Product 1', category: { id: 1, name: 'Category 1' }, price: 10.99 },
    { id: 2, name: 'Product 2', category: { id: 2, name: 'Category 2' }, price: 19.99 },
    { id: 3, name: 'Product 3', category: { id: 1, name: 'Category 1' }, price: 15.99 },
    { id: 4, name: 'Product 4', category: { id: 3, name: 'Category 3' }, price: 29.99 },
    { id: 5, name: 'Product 5', category: { id: 2, name: 'Category 2' }, price: 9.99 }
  ];

  products = signal<Product[]>(this.listProducts);

  getProducts(): Signal<Product[]> {
    return this.products.asReadonly();
  }

  setProducts(setListProducts: Product[]) {
    this.products.update(value => value = setListProducts);
  }
}

Category service:

import { inject, Injectable, signal, WritableSignal } from '@angular/core';
import { ProductsService } from './products.service';
import { Category, Product } from '../models/models';

@Injectable({
  providedIn: 'root'
})
export class CategoriesService {
  listCategories: Category[] = [
    { id: 1, name: 'Category 1' },
    { id: 2, name: 'Category 2' },
    { id: 3, name: 'Category 3' }
  ];
  categories = signal<Category[]>([]);
  selectedCategory = signal<Category>(this.listCategories[0]);
  private productsService = inject(ProductsService);

  getCategories(): WritableSignal<Category[]> {
    this.categories.update(value => value = [...this.listCategories]);
    return this.categories
  }

  setSelectedCategory(category: Category) {
    this.selectedCategory.update(el => el = category);
    const listProductsFilter = this.productsService.listProducts.filter((value: Product) => value.category.id === category.id)
    this.productsService.setProducts(listProductsFilter);
  }
}

Both services contain sample data not fetched from the server.

The SRP principle recommends separating coupled components and reducing their responsibility to a single functionality.

(OCP) Open/Closed Principle

States “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”. Bertrand Meyer is usually credited with the creation of this principle. He described it in his book “Object-Oriented Software Construction” from 1988.

I would suggest using reusable components. By creating a component where properties are injected via input. Such components are open for extension but closed for modification. In other words, if we do not want to use a particular setting passed in input we simply do not provide that property in the component. For example, below is a button component that can be used in different places with different settings provided in the input properties:

import { Component, input, output } from '@angular/core';

@Component({
  selector: 'app-button',
  template: `
  <div class="{{cssClass()}}" (click)="onClick()">
    {{label()}} 
  </div>
  `,
  styles: `
    .button  { 
      cursor: pointer; 
      width: max-content;   
      padding: 10px;
      background-color: rgb(197, 133, 133);
    }`
})
export class ButtonComponent {
  label = input('')
  cssClass = input('')
  submitClick = output();

  onClick(): void {
    this.submitClick.emit();
  }
}

Usage of the app-button component in other components:

<app-button [label]="'title'" [cssClass]="'button'" />

You can add other input properties to this app-button component, such as button type, visibility, disablement, etc. Therefore, I believe that such components adhere to the Open/Closed Principle. If we do not want to use an input property, we simply do not pass it. In this way, we are not modifying the existing methods, in this case, the input properties.

(LSP) Liskov Substitution Principle

The design principle in object-oriented programming stating that: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing exactly the types of those objects.

The principle was first formulated by Barbara Liskov in the book “Data Abstraction and Hierarchy”, and later popularized and presented in its current form by Robert C. Martin in the article “Principles of Object Oriented Design” and the book “Agile Software Development: Principles, Patterns, and Practices”.

First, I will present incorrectly written classes that violate the Liskov Substitution Principle.

I have three classes: Animal with two methods move and fly because animals usually walk but sometimes fly as well. The second class, Bird, inherits from the Animal class and has two methods because birds usually walk and fly. The third class, Ostrich, has the move method because ostriches walk and a fly method that generates an exception because ostriches do not fly:

import { Component } from '@angular/core';


class Animal {
  move() {
    console.log('Animal I can move ');
  }
  fly() {
    console.log('Animal I can fly');
  }
}


class Bird extends Animal {
  override move() {
    console.log('Bird I can move');
  }
  override fly() {
    console.log('Bird I can fly');
  }
}


class Ostrich extends Animal {
  override fly() {
    throw new Error('Ostrich I cannot fly');
  }

  override move() {
    console.log('Ostrich I can move, but I cannot fly ');
  }
}


@Component({
  selector: 'app-zasada-podstawienia-liskov',
  templateUrl: './zasada-podstawienia-liskov.component.html',
  styleUrl: './zasada-podstawienia-liskov.component.scss'
})
export class ZasadaPodstawieniaLiskovComponent extends Animal {

  constructor() {
    super();

    const animal = new Array()
    animal[0] = new Bird();
    animal[1] = new Ostrich();

    animal.forEach(animal => {
      animal.move();
      animal.fly();  // Error: Ostrich I cannot fly
    })
  }
}

There are many mistakes in these classes. The first one is the fly method in the Animal class. This is an incorrect assumption because not all animals fly; most only move. The second issue is the method generating an exception in the Ostrich class. It makes no sense to call a method that generates an error.

Now, we need to fix these errors and refine them to comply with the Liskov Substitution Principle. The fly method should be extracted from the Animal class into another class so that other classes can inherit it if needed. The method generating the exception needs to be cleaned up. We need to add a verification to check if the object is of type Animalfly and then call the appropriate fly method if it is:

import { Component } from '@angular/core';

class Animal {
  move() {
    console.log('Animal I can move ');
  }
}


class Animalfly extends Animal {
  fly() {
    console.log('Animalfly I can fly');
  }
}


class Bird extends Animalfly {
  override move() {
    console.log('Bird I can move ');
  }
  override fly() {
    console.log('Bird I can fly');
  }
}



class Ostrich extends Animal {
  override move() {
    console.log('Ostrich I can move, but I cannot fly ');
  }
}


@Component({
  selector: 'app-zasada-podstawienia-liskov',
  templateUrl: './zasada-podstawienia-liskov.component.html',
  styleUrl: './zasada-podstawienia-liskov.component.scss'
})
export class ZasadaPodstawieniaLiskovComponent extends Animal {

  constructor() {
    super();

    const animals = new Array()
    animals[0] = new Bird();
    animals[1] = new Ostrich();

    animals.forEach(animal => {
      animal.move(); 

      if (animal instanceof Animalfly) {
        (animal).fly();
      }
    })
  }
}

In summary, only the necessary methods are included in the base class. We do not add methods that do not always meet the assumptions. So, if we have several classes and a method from the base class does not fit a particular class, we delegate it to a separate class so that only the classes that need it can inherit from it. In our case, this is the Animalfly class with the fly method extracted from the base Animal class.

(ISP) Interface Segregation Principle

States that no code should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

For example, during user registration, a form with many fields such as first name, last name, address, and login must be filled out. However, after logging in, not all user data needs to be displayed in every component. The initial interface model for user registration might look like this:

export interface User {
   firstName: string;
   lastName: string;
   login: string;
   
   phone: string;
   email: string; 

   street: string;
   houseNumber: string;
   apartmentNumber: string;
   city: string;
   zipCode: string;
   country: string;
}

This interface model does not adhere to the Interface Segregation Principle. It should be broken down into smaller, more specific interfaces:

export interface User {
   firstName: string;
   lastName: string;
   login: string;
   phone: string;
   contactDetails: ContactDetails;
   address: Address;
}


export interface ContactDetails {
   phone: string;
   email: string; 
}

export interface Address {
   street: string;
   houseNumber: string;
   apartmentNumber?: string;
   city: string;
   zipCode: string;
   country: string;
}

This interface model does not adhere to the Interface Segregation Principle, as it includes all fields, which may not always be needed for displaying, editing, or deleting. In my opinion, to ensure that the model and interface comply with the Interface Segregation Principle, which means implementing only the methods required in a given component, it should be segmented as follows:

 export interface User {
   firstName: string;
   lastName: string;
   login: string; 
   contactDetails?: ContactDetails;
   address: Address;
}

export interface ContactDetails {
   phone: string;
   email: string; 
}

export interface Address {
   street: string;
   houseNumber: string;
   apartmentNumber?: string;
   city: string;
   zipCode: string;
   country: string;
}
 
export interface GetDetailedUser {
   getFirstName(): string;
   getLastName(): string;     
   getLogin(): string;   
   getContactDetails?(): ContactDetails;
   getAddress?(): Address;
   getUser?(): User;
}

export interface SetDetailedUser {  
   setFirstName(firstName: string): void;   
   setLastName(lastName: string): void;   
   setLogin(login: string): void;
   setContactDetails?(contactDetails: ContactDetails): void;  
   setAddress?(address: Address): void;  
   setUser?(user: User): void;  
}

export interface GetContactDetails {
   getPhone(): string; 
   getEmail(): string; 
}

export interface SetContactDetails {
   setPhone(phone: string): void;
   setEmail(email: string): void;   
}

export interface GetAddress {
   getStreet(): string;
   getHouseNumber(): string;
   getApartmentNumber?(): string;
   getCity(): string;
   getZipCode(): string;
   getCountry(): string;
   getAddress?(): Address
}

export interface SetAddress {
   setStreet(street: string): void;
   setHouseNumber(houseNumber: string): void;
   setApartmentNumber?(apartmentNumber: string): void;
   setCity(city: string): void;
   setZipCode(zipCode: string): void;
   setCountry(country: string): void;
   setAddress?(address: Address): void;
}

In TypeScript, there are several utility types that facilitate common type transformations by creating one type from another. They can help adhere to the Interface Segregation Principle, and include Omit<Type, Keys>, and Pick<Type, Keys> Below is an example of their usage:

export interface User {
   firstName: string;
   lastName: string;
   login: string; 
   contactDetails?: ContactDetails;
   address: Address;
}

export interface ContactDetails {
   phone: string;
   email: string;
}

export interface Address {
   street: string;
   houseNumber: string;
   apartmentNumber?: string;
   city: string;
   zipCode: string;
   country: string;
}

type UserName = Pick<User, 'firstName' | 'lastName'>;

const userName: UserName = {
   firstName: "Zofia",
   lastName: 'Kowalska',
};


type UserAddressPreview = Omit<Address, 'country'>;

const todo: UserAddressPreview = {
   street: 'New',
   houseNumber: '123',
   apartmentNumber: '9a',
   city: 'Szczecin',
   zipCode: '12345'
};

Pick selected keys from a given type to include in the new type. Omit excludes specified keys from a given type to create a new type.

(DIP) Dependency Inversion Principle

It states that high-level modules should not depend on low-level modules — dependencies between them should be based on abstractions. Thus, an abstraction should be applied between a high-level module and a low-level module.

In the example below, there is no abstraction class or interface definition, which would facilitate adding or modifying the data returned from the API (low-level class):

 
export const customers: any[] = [
  { id: 1, name: 'John' },
  { id: 2, name: 'Jane' },
  { id: 3, name: 'Jack' }
];
// low-level class
@Injectable({
  providedIn: 'root'
})
export class CustomerService  {

  getCustomers(): Observable<any[]> {
    return of(customers);
  }
}

high-level class:

import { Component, inject } from '@angular/core';
import { AsyncPipe } from '@angular/common';
import { CustomerService } from '../services/customer.service';

@Component({
  selector: 'app-zasada-odwrocenia-zaleznosci',
  standalone: true,
  imports: [AsyncPipe],
  providers:[CustomerService],
  template: `
    @for (item of listCustomers$ | async; track item.id) {
    <li>{{ item.name }}</li>
    } @empty {
    <li>There are no items.</li>
    }
  `,
  styleUrl: './zasada-odwrocenia-zaleznosci.component.scss'
})
export class ZasadaOdwroceniaZaleznosciComponent {
  protected readonly listCustomers$ = inject(CustomerService).getCustomers()
}

By adding an abstract class and an interface, in case of a change in the object returned by the API, it is sufficient to modify the Customer interface:

import { Injectable } from '@angular/core';
import { Observable, of } from 'rxjs';

export interface Customer {
  id: number;
  name: string;
}
export abstract class ICustomerRepository {
  abstract getCustomers(): Observable<Customer[]>;
}
export const customers: Customer[] = [
  { id: 1, name: 'John' },
  { id: 2, name: 'Jane' },
  { id: 3, name: 'Jack' }
];

// high level class
@Injectable({
  providedIn: 'root'
})
export class CustomerService extends ICustomerRepository {

  getCustomers(): Observable<Customer[]> {
    return of(customers);
  }
}

Below is a view of the component template:

import { Component, inject } from '@angular/core';
import { AsyncPipe } from '@angular/common';
import { CustomerService, ICustomerRepository } from '../services/customer.service';

// low level class
@Component({
  selector: 'app-zasada-odwrocenia-zaleznosci',
  standalone: true,
  imports: [AsyncPipe],
  providers: [{
    provide: ICustomerRepository,
    useClass: CustomerService
  }],
  template: `
    @for (item of listCustomers$ | async; track item.id) {
    <li>{{ item.name }}</li>
    } @empty {
    <li>There are no items.</li>
    }
  `,
  styleUrl: './zasada-odwrocenia-zaleznosci.component.scss'
})
export class ZasadaOdwroceniaZaleznosciComponent {
  protected readonly listCustomers$ = inject(CustomerService).getCustomers()
}

Summary:

I believe that programming according to SOLID principles is the best approach to software design, especially in the context of object-oriented programming like Angular. It may seem challenging, but I think that adhering to these principles can bring significant benefits to code quality, scalability, flexibility, and ease of maintenance.

Materials:

1. https://pl.wikipedia.org/wiki/SOLID
2. https://pl.wikipedia.org/wiki/Robert_C._Martin
3. https://coderslab.pl/pl/blog/zasady-solid-programowanie-zgodne-z-dobrymi-praktykami
4. https://www.p-programowanie.pl/paradygmaty-programowania/zasady-solid
5. https://www.typescriptlang.org/docs/handbook/utility-types.html

I’m not good at English. I write articles to practice English.

Principles SOLID in Angular was originally published in Principles SOLID in Angular on Medium, where people are continuing the conversation by highlighting and responding to this story.