# Inversion of Control

Để hiểu được IoC là gì, trước tiên ta hãy cắt nghĩa của từ **Inversion và Control**

- **Inversion** khi dịch ra Tiếng Việt có nghĩa là đảo ngược
- **Control** có nghĩa là quyền kiểm soát

Vậy **Inversion of Control** có nghĩa là đảo ngược quyền kiểm soát hay chuyển quyền điều khiển từ bên trong ra bên ngoài một scope. Nghe có vẻ khó hiểu phải không? Đừng lo, chúng ta sẽ cùng nhau tìm hiểu qua ví dụ sau:
```typescript

function submitFeedback(feedback: string, onDone?: () => void) {
  // Gửi feedback lên server

  onDone?.();
}

function main() {
  const feedback = inputElement.value;

  submitFeedback(feedback, () => {
    alert('Feedback đã được gửi thành công');
  });
}
```

Trong đoạn code trên, hàm **submitFeedback** nhận vào hai tham số là **feedback** và **onDone**. Khi gọi hàm **submitFeedback**, chúng ta truyền vào feedback và một hàm callback **onDone** để xử lý sau khi feedback đã được gửi lên server.

Trong trường hợp này, hàm **alert** được định nghĩa trong hàm **main** và được thực thi trong hàm **submitFeedback**. 

Điều này có nghĩa là hàm **submitFeedback** không cần biết cách thức xử lý của hàm **onDone**, mà nó chỉ cần gọi hàm **onDone** khi xử lí việc submit feedback. Điều này có nghĩa là chúng ta chuyển quyền điều khiển của hàm **submitFeedback** ra bên ngoài - tức hàm **main**.

Điều này chính là một ví dụ về Inversion of Control.

Chúng ta sẽ thấy những trường hợp tương tự như vậy trong các hệ thống bất đồng bộ hoặc trong các hệ thống xử lý sự kiện: xử lí các DOM event, xử lí liên quan đến network như lắng nghe các sự kiện từ socket,...

Vậy tại sao chúng ta cần phải sử dụng Inversion of Control?

- **Flexible - Tăng tính linh hoạt**: Khi sử dụng Inversion of Control, chúng ta có thể dễ dàng thay đổi cách thức xử lý của một hàm mà không cần phải thay đổi nội dung của hàm đó.
- **Maintainable and Extendable - Dễ bảo trì và mở rộng**: Khi chúng ta chuyển quyền kiểm soát từ bên trong hàm ra bên ngoài, chúng ta có thể dễ dàng thay đổi cách thức xử lý của hàm đó mà không ảnh hưởng đến các phần khác trong hệ thống.
- **Testable - Dễ kiểm thử**: Khi chúng ta chuyển quyền kiểm soát ra bên ngoài, chúng ta có thể dễ dàng kiểm thử các phần logic mà không cần phải kiểm thử toàn bộ hàm.

Ba lợi ích trên cũng là ba mục tiêu mà chúng ta cần đạt được khi xây dựng một hệ thống phần mềm.

# Dependency Injection

Dependency Injection là một design pattern giúp chúng ta quản lý các dependency giữa các module trong hệ thống. Nó cũng áp dụng nguyên lí Inversion of Control để chuyển quyền điều khiển việc khởi tạo các dependency từ bên trong module ra bên ngoài.

Ví dụ sau sẽ giúp chúng ta hiểu rõ hơn về Dependency Injection:

```typescript
class Logger {
  construction() {}
}

class Database {
  construction() {
    this.logger = new Logger();
  }
}

class UserService {
  construction() {
    this.database = new Database();
    this.logger = new Logger();
  }
}

class UserService {
  construction() {
    this.database = new Database();
    this.logger = new Logger();
  }
}

class AuthService {
  construction() {
    this.userService = new UserService();
    this.logger = new Logger();
  }
}

const authService = new AuthService();
```

Trong ví dụ trên, chúng ta có bốn class **Logger**, **Database**, **UserService** và **AuthService**. Mỗi class này đều khởi tạo các dependency của nó trong constructor.


<Image
  src="/images/DI.svg"
  title="Denpendency Graph"
/>

Với cách cài đặt trên, có một số nhược điểm như sau:
- **Khó kiểm thử**: Khi chúng ta kiểm thử một class, chúng ta không có cách nào mock các dependency của class đó. Ví dụ như khi chúng ta kiểm thử class **UserService**, chúng ta không thể mock class **Database** hoặc class **Logger**.
- **Khó mở rộng**: Khi chúng ta muốn thay đổi cách thức khởi tạo của một dependency, chúng ta phải thay đổi tại nơi chúng được sử dụng mặc dù logic đó chỉ nên nằm ở class, nơi mà thay đổi đó được áp dụng.
- **Khó bảo trì**: Khi chúng ta muốn thay đổi một dependency, chúng ta phải thay đổi tại nơi chúng được sử dụng. Điều này dẫn đến việc chúng ta phải thay đổi nhiều nơi trong hệ thống.

Chúng ta sẽ thay đổi ví dụ trên bằng cách khởi tạo các dependency từ bên ngoài và truyền vào qua constructor như sau:

```typescript
class Logger {
  construction() {}
}

class Database {
  construction(private logger: Logger) {}
}

class UserService {
  construction(private database: Database, private logger: Logger) {}
}

class AuthService {
  construction(private userService: UserService, private logger: Logger) {}
}

const database = new Database(new Logger());
const userService = new UserService(database, new Logger());
const authService = new AuthService(userService, new Logger());
```

Như vậy, chúng ta đã giải quyết được các nhược điểm của việc khởi tạo dependency trong constructor. T có thể dễ dàng kiểm thử các class mà không cần phải mock các dependency. Tuy nhiên, những nhược điểm còn lại như khó mở rộng và khó bảo trì vẫn chưa được giải quyết. Mỗi khi thay đổi cách thức khởi tạo của một dependency, chúng ta vẫn phải thay đổi tại những nơi chúng được sử dụng.

Để giải quyết vấn đề này, chúng ta sử dụng một design pattern khác gọi là **Dependency Injection Container**. Dependency Injection Container giúp quản lý các dependency và cung cấp chúng cho các class mà chúng ta cần.

```typescript
class Logger {
  construction() {}
}

class Database {
  construction(private logger: Logger) {}
}

class UserService {
  construction(private database: Database, private logger: Logger) {}
}

class AuthService {
  construction(private userService: UserService, private logger: Logger) {}
}

class Container {
  private store = new Map();

  private getDependenciesOf<T>(Type<T>): any[] {
    // Lấy ra các dependency của một class dựa vào constructor của class đó
    ...    
  }

  register(T: Type) {
    this.store.set(Symbol.for(T.name), null);
  }

  resolve<T>(type: Type): T {
    // Lấy ra instance từ store và kiểm tra xem nó đã được khởi tạo chưa
    let instance = this.store.get(Symbol.for(Type.name));

    // Nếu instance chưa được khởi tạo, khởi tạo nó
    if (!instance) {
      // Lấy ra các dependency của class và resolve chúng
      const dependecyTypes = this.getDependenciesOf(T);
      const dependencies = dependecyTypes.map(dependency => this.resolve(dependency));

      // Khởi tạo class và lưu vào store
      instance = new T(...dependencies);
      this.store.set(Symbol.for(key), new T(...instance));
    }

    // Trả về instance
    return instance;
  }
}

const container = new Container();
container.register(Logger);
container.register(Database);
container.register(UserService);
container.register(AuthService);
const authService = container.resolve<AuthService>(AuthService);
```

Với cải tiến trên, chúng ta đã giải quyết được các nhược điểm của việc khởi tạo dependency trong constructor. Chúng ta cũng dễ dàng mở rộng và bảo trì hệ thống mà không cần phải thay đổi nhiều nơi trong hệ thống.

Ngoài ra, bằng việc sử dụng container, chúng ta cũng có thể quản lý và sử dụng các dependency một cách dễ dàng hơn, mỗi một class chỉ được khởi tạo 1 lần và được sử dụng lại ở các nơi khác nhau trong hệ thống (có thể đều chỉnh để class có thể được tạo mới mỗi lần cần thiết).

Bên cạnh những ưu điểm, Dependency Injection Container cũng có nhược điểm là làm tăng độ phức tạp của hệ thống và làm cho việc debug trở nên khó khăn hơn vì việc khởi tạo các dependency không còn nằm trong constructor của class nữa.

Do việc khai báo và sử dụng các dependency không còn nằm trong constructor nữa, nên các lập trình viên có thể sẽ không quan tâm tới dependency graph dẫn đến việc khó kiểm soát và quản lý các dependency khi hệ thống trở nên phức tạp.

# Tóm lại

Có rất nhiều thư viện hỗ trợ Dependency Injection như **Angular**, **NestJS**, **fastapi**,... để hỗ trợ lập trình viên quản lý các dependency giữa các module trong hệ thống một cách dễ dàng và hiệu quả.

Inversion of Control và Dependency Injection là hai khái niệm quan trọng trong lập trình hướng đối tượng. Nó là những nguyên lý cơ bản giúp chúng ta xây dựng các ứng dụng linh hoạt, dễ bảo trì và mở rộng. Tuy nhiên, hãy sử dụng chúng một cách cẩn thận và hợp lý để tránh tình trạng hệ thống trở nên phức tạp và khó bảo trì.

Hi vọng bài viết này giúp bạn hiểu rõ hơn về Inversion of Control và Dependency Injection. Hãy để lại comment nếu bạn có bất kỳ thắc mắc hoặc ý kiến nào về bài viết này nhé!

Happy coding!

Observer pattern (một số tài liệu khác ghi là pubsub pattern) là một behavior design pattern.
Về định nghĩa, mình sử dụng luôn định nghĩa trên wikipedia như sau:

> In software design and engineering, the observer pattern is a software design pattern in which an object,
named the subject, maintains a list of its dependents, called observers, and notifies them automatically of
any state changes, usually by calling one of their methods.

Về cơ bản, observer pattern giúp chúng ta giải quyết vấn đề về việc thông báo cho các thành phần khác biết về sự thay đổi của một thành phần nào đó. Điều này giúp chúng ta giảm thiểu sự phụ thuộc giữa các thành phần trong hệ thống, giúp chúng ta dễ dàng mở rộng hệ thống mà không cần phải thay đổi nhiều mã nguồn.

Trong bài viết này, mình sẽ áp dụng observer pattern để cấu trúc một todo application cơ bản:
- thêm task
- update task
- xóa task


## Cấu trúc project

Ở đây mình sẽ sử dụng vite để tạo project mới tên todo-app

```bash
$ npm create vite@latest todo-app -- --template vanilla-ts
```

Sau khi xóa một vài files không cần thiết, chúng ta sẽ có cấu trúc project như sau:

```
.
├── index.html
├── package.json
├── public
│   └── vite.svg
├── src
│   ├── main.ts
│   └── vite-env.d.ts
├── tsconfig.json
└── yarn.lock

3 directories, 7 files
```

## Cài đặt observer pattern

Đầu tiên, chúng ta sẽ tạo một class **Observer** để quản lý các observer. Mỗi observer sẽ có một method **update** để nhận thông báo từ subject.
Ngoài ra, chúng ta tạo luôn một object **Observable** có 3 methods:
- registerObserver - thêm 1 observer vào danh sách listener
- unregisterObserver - xóa một observer vào danh sách listener
- notifyObservers - trigger các listener khi có update

```typescript
class Observer {
  update() {
    throw new Error("Method not implemented.");
  }
}

class Observable {
  private observers: Observer[];

  constructor() {
    this.observers = [];
  }

  registerObserver(observer: Observer) {
    this.observers.push(observer);
  }

  unregisterObserver(observer: Observer) {
    this.observers = this.observers.filter((o) => o !== observer);
  }

  notifyObservers() {
    this.observers.forEach((o) => o.update());
  }
}
```

## Áp dụng observer pattern vào todo application

Trong trường hợp của todo application, Observer là UI hiển thị trên browser và Observable là data model bên dưới application.
Bất kì những thay đổi bên dưới data model này sẽ được ánh xạ lên trên UI.

Tạo một **TaskModel** kế thừa **Observable** class, trong class này sẽ thực hiện mọi logic để maintain danh sách task của todo application.

```typescript
class TaskModel extends Observable {
  private tasks: Task[];

  constructor() {
    super();
    this.tasks = [];
  }

  addTask(task: Omit<Task, "id">) {
    this.tasks.push({
      id: uuidV4(),
      ...task,
    });
    this.notifyObservers();
  }

  getTasks() {
    return this.tasks;
  }

  updateTask(task: Task) {
    this.tasks = this.tasks.map((t) => (t.id === task.id ? task : t));
    this.notifyObservers();
  }
}
```

**TaskView** chứa logic cho việc hiển thị data lên UI của browser (được gọi là View).
Ngoài ra, **TaskView** sẽ truyền event từ UI về data model khi user tương tác với UI.

```typescript
class TaskView extends Observer {
  private model: TaskModel;
  private container: HTMLUListElement;

  constructor(model: TaskModel, container: HTMLUListElement) {
    super();
    this.model = model;
    this.container = container;
    this.model.registerObserver(this);
  }

  update() {
    this.container.innerHTML = "";
    this.model.getTasks().forEach((task) => {
      const li = document.createElement("li");
      li.textContent = task.name;
      li.onclick = () => {
        this.model.updateTask({
          ...task,
          completed: !task.completed,
        });
      };
      task.completed && (li.style.textDecoration = "line-through");
      this.container.appendChild(li);
    });
  }
}
```

Cuối cùng, chúng ta sẽ khởi tạo **TaskModel**, **TaskView** trong **main.ts**, và gắn chúng vào DOM của browser:

```typescript
document.addEventListener("DOMContentLoaded", () => {
  const form = document.getElementById("todo-form") as HTMLFormElement;
  const input = document.getElementById("todo-input") as HTMLInputElement;
  const todoContainer = document.getElementById("todo-list") as HTMLUListElement;

  const model = new TaskModel();
  const view = new TaskView(model, todoContainer);

  form.addEventListener("submit", (event) => {
    event.preventDefault();
    model.addTask({
      name: input.value,
      completed: false,
    });
    input.value = "";
    return false;
  });
});
```

## Kết luận

Bằng việc sử dụng observer pattern, chúng ta đã phân tách được phần logic ứng dụng và phần hiển thị trên UI, giúp cho code trở nên dễ đọc và dễ bảo trì hơn.
Ngoài ra, observer pattern còn được sử dụng trong các framework lớn như React, Angular, Vue để quản lý state và hiển thị trên UI.

Link github: [todo-app](https://github.com/magiskboy/todo-observer-pattern)

Ta có 5 nguyên lí thiết kế bắt buộc phải tuân theo khi chúng ta thiết kế ứng dụng theo hướng đối tượng, mình sẽ chia sẻ các nguyên lí trong bài viết này.
Chúng ta có 5 nguyên lí, gọi tắt là __SOLID__

* Single responsibility principle
* Open/Close principle
* Liskov principle
* Interface segregation principle
* Dependencies Inversion principle


### Ta nói về nguyên lí đầu tiên, S — Single responsibility

Hiểu nôm na nguyên lí này hướng người thiết kế đến mục tiêu là mỗi một class viết ra sẽ chỉ dùng cho 1 mục đích hay 1 nhiệm vụ cụ thể.

Giả sử bạn cần viết một class ConnectDatabase, bạn chỉ nên cài đặt các phương thức phục vụ mục đích tạo kết nối tới database mà không nên cài đặt các phương thức khác như query hay đóng kết nối.

Nguyên lí này giúp lập trình viên kiểm soát tốt thiết kế và luồng hoạt động của ứng dụng, dễ dàng bảo trì, sửa lỗi cho ứng dụng.

<Image
	src="https://miro.medium.com/max/700/0*DWendOmHviffM4Au"
	title="Photo by Andreas Wagner on Unsplash"
/>

### Nguyên lí thứ 2 là O — Open/Close principle

Nguyên lí này nhắc nhở lập trình viên rằng hãy viết class có thể mở rộng mà không được phép sửa đổi các class khác.

Hãy lấy ví dụ sau:
Giả sử chúng ta có một class là ProductLogs, class này có chức năng quản lí việc log thông tin sản phẩm trên một hệ thống thương mại điện tử. Trong class ProductLogs này bạn có phương thức cài đặt thuật toán bubble sort để sắp xếp các log. Sau một thời gian, bubble sort làm chậm quá trình sắp xếp và bạn muốn thay bubble sort bằng quick sort. Thay vì sửa code trong lớp ProductLogs, bạn tạo ra 1 class mới tên QuickProductLogs kế thừa class ProductLogs với việc Override phương thức sort.

Bằng cách áp dụng nguyên lí này, các lập trình viên dễ dang tái sử dụng code cũng như đem laị sự ổn định cho code, kiểm soát code tốt hơn.

<Image
	src="https://miro.medium.com/max/700/0*Ict0nXXku3iJPjAU"
	title="Photo by Philipp Berndt on Unsplash"
/>

### Nguyên lí thứ 3 mình sẽ nhắc tới đó là L — Liskov principle

Nguyên lí Liskov nói rằng

```
Nếu class T kế thừa class P thì ta có thể thay thế các class P bằng class T sao cho logic chương trình không bị thay đổi.
```

Nguyên lí này đã sử dụng triệt để nguyên lí kế thừa của lập trình hướng đối tượng. Các bạn khi tạo ra một class kế thừa một class khác, các bạn chỉ nên mở rộng mà không nên thay đổi behavior của class cha.

Ta lấy một ví dụ, bạn tạo ra một class là SimpleSort có phương thức sort và sau đó boss của bạn hiệu năng của việc sắp xếp cao hơn và bạn quyết định cài đặt thuật toán quick sort. Bạn kế thừa SimpleSort và override lại phương thức sort, good job! Vậy là bạn có thuật toán mới mà không làm thay đổi behavior của class cha đó là sắp xếp.

<Image
	src="https://miro.medium.com/max/700/0*J9q6aGky0ap_si3A"
	title="Photo by Huy Phan on Unsplash"
/>

### Nguyên lí tiếp theo sẽ là I — Interface segregation principle

Nguyên lí này muốn chúng ta chia một task thành các task nhỏ hơn, tránh việc một class phải cài đặt thừa chức năng mà nó đảm nhiệm

Ta cùng lấy ví dụ về nguyên lí này. Giả sử một cửa hàng có cả nhân viên bán hàng và máy bán hàng tự động. Người nhân viên thì có các hành vi như ăn, ngủ, thể dục, kiểm hàng, tính tiền và thu tiền. Bên cạnh đó, máy bán hàng thì chỉ có các hành vi kiểm hàng, tính tiền và thu tiền. Right?. Như vậy nếu bạn tạo ra 1 interface là IEmployee bao gồm các phương thức ăn, ngủ, thể dục, kiểm hàng, tính tiền và thu tiền thì máy bán hàng phải implement các phương thức không cần thiết như ăn, ngủ, thể dục.

Thay vào đó, ta sẽ có thiết kế tốt hơn bằng việc chia IEmployee thành IHuman gồm các phương thức ăn, ngủ, thể dục và IEmployee gồm kiểm hàng, tính tiền và thu tiền.
Người bán hàng — HumanEmployee sẽ implement cả 2 interface này còn máy bán hàng — MachineEmployee sẽ chỉ implement interface thứ 2.

Việc áp dụng nguyên lí này không đúng cách sẽ là hệ thống trở nên phức tạp và rối rắm nên khi áp dụng nguyên lí này, các bạn nên cân nhắc xem có nên chia hay không nhé :smile:

<Image
	src="https://miro.medium.com/max/700/0*A0t9PwrBbs4fdJUG"
	title="Photo by John Doyle on Unsplash"
/>

### Nguyên lí cuối cùng mình sẽ giới thiệu đó là D — Dependencie Inversion principle

Nguyên lí này nói rằng, các cài đặt chỉ phụ thuộc vào các bên trừu tượng (high level) hơn nó và không phụ thuộc vào các cài đặt cụ thể.

Nôm na là khi kế thừa, các class cụ thể sẽ chỉ kế thừa từ abstract class hoặc implement interface mà không kế thừa từ class được cài đặt cụ thể.

Hãy cùng lấy ví dụ: giả sử bạn có 1 class cài đặt thuật toán ShellSort và bạn muốn tăng hiệu năng ứng dụng bằng thuật toán QuickSort. Bạn không nên kế thừa từ ShellSort mà hay tạo ra một interface ISort và cả ShellSort và QuickSort implement ISort, như vậy thiết kế của bạn trông rất clear và code sẽ dễ hiểu cũng như mở rộng, hãy thử và cảm nhận :)).


<Image
	src="https://miro.medium.com/max/700/0*2yWMW5cN1bJandNg"
	title="Photo by Henry & Co. on Unsplash"
/>

Việc áp dụng các nguyên lí không chỉ giúp code tái sử dụng, dễ sửa chữa và bảo trì, nó còn là ngôn ngữ chung giúp các thành viên trong team dễ dàng trao đổi vào hiểu code của nhau.


Mình sẽ kết thúc bài viết ở đây. Hi vọng bài viết sẽ giúp mọi người có cái nhìn cơ bản về SOLID.

Design pattern

Từ Inversion of Control đến Dependency Injection

Sử dụng observer pattern trong lập trình web

SOLID Principles