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

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

SOLID Principles