From 3336e9fb8288c3aff95e23016f7c4d9ad7b563fe Mon Sep 17 00:00:00 2001
From: PhucVR <59957741+nguyenphuc22@users.noreply.github.com>
Date: Thu, 1 Feb 2024 20:49:32 +0700
Subject: [PATCH] Add changes to .idea/workspace.xml,
 Writerside/topics/Observer.md, and docs/Book/Struct.md

---
 .idea/workspace.xml           | 33 +++++++++++++++++++++++++++++++-
 Writerside/topics/Observer.md | 36 ++++++++++++++++++++++-------------
 docs/Book/Struct.md           |  1 +
 3 files changed, 56 insertions(+), 14 deletions(-)

diff --git a/.idea/workspace.xml b/.idea/workspace.xml
index e852f33..927c496 100644
--- a/.idea/workspace.xml
+++ b/.idea/workspace.xml
@@ -4,7 +4,11 @@
     <option name="autoReloadType" value="SELECTIVE" />
   </component>
   <component name="ChangeListManager">
-    <list default="true" id="3cb5d028-bd6e-41c8-8344-b58383b29cf7" name="Changes" comment="" />
+    <list default="true" id="3cb5d028-bd6e-41c8-8344-b58383b29cf7" name="Changes" comment="">
+      <change beforePath="$PROJECT_DIR$/.idea/workspace.xml" beforeDir="false" afterPath="$PROJECT_DIR$/.idea/workspace.xml" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/Writerside/topics/Observer.md" beforeDir="false" afterPath="$PROJECT_DIR$/Writerside/topics/Observer.md" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/docs/Book/Struct.md" beforeDir="false" afterPath="$PROJECT_DIR$/docs/Book/Struct.md" afterDir="false" />
+    </list>
     <option name="SHOW_DIALOG" value="false" />
     <option name="HIGHLIGHT_CONFLICTS" value="true" />
     <option name="HIGHLIGHT_NON_ACTIVE_CHANGELIST" value="false" />
@@ -19,6 +23,33 @@
   <component name="InstanceColorv3">
     <option name="map">
       <map>
+        <entry key="$PROJECT_DIR$/Writerside/hi.tree">
+          <value>
+            <ColorState>
+              <option name="customOrder" value="2" />
+              <option name="first">
+                <RgbState>
+                  <option name="blue" value="225" />
+                  <option name="darkBlue" value="225" />
+                  <option name="darkGreen" value="149" />
+                  <option name="darkRed" value="56" />
+                  <option name="green" value="149" />
+                  <option name="red" value="56" />
+                </RgbState>
+              </option>
+              <option name="second">
+                <RgbState>
+                  <option name="blue" value="234" />
+                  <option name="darkBlue" value="234" />
+                  <option name="darkGreen" value="197" />
+                  <option name="darkRed" value="81" />
+                  <option name="green" value="197" />
+                  <option name="red" value="81" />
+                </RgbState>
+              </option>
+            </ColorState>
+          </value>
+        </entry>
         <entry key="hi.tree">
           <value>
             <ColorState>
diff --git a/Writerside/topics/Observer.md b/Writerside/topics/Observer.md
index 700559b..25a8c53 100644
--- a/Writerside/topics/Observer.md
+++ b/Writerside/topics/Observer.md
@@ -13,27 +13,37 @@
 - **Ý Tưởng Cốt Lõi:** Trong Observer Pattern, 'Subject' đóng vai trò là nhà xuất bản (publisher), trong khi 'Observers' đóng vai trò như các người đăng ký (subscribers). Mỗi khi 'Subject' có một thay đổi trạng thái, nó sẽ thông báo cho tất cả 'Observers' của mình. Điều này cho phép tách biệt giữa 'Subject' và 'Observers', tăng cường tính mô-đun và dễ dàng mở rộng hệ thống. 'Observers' có thể đăng ký hoặc hủy đăng ký với 'Subject' một cách linh hoạt mà không ảnh hưởng tới 'Subject' hoặc các 'Observers' khác.
 
 
-## Đặt vấn đề
+### Đặt vấn đề
 
-Giả sử bạn đang phát triển một website thương mại điện tử với các chức năng sau:
+Trong một hệ thống phần mềm, việc theo dõi và phản ứng với các thay đổi trạng thái là một thách thức phổ biến. Xét tình huống của một ứng dụng thương mại điện tử, nơi thông tin sản phẩm cần được cập nhật thường xuyên trên nhiều giao diện như trang chủ, trang chi tiết sản phẩm, và trang quản lý hàng tồn kho. Khi không sử dụng một pattern như Observer Pattern, việc cập nhật trạng thái này trở nên phức tạp và không hiệu quả. Mỗi lần thông tin sản phẩm thay đổi, phải thực hiện nhiều lần gọi và cập nhật trên các giao diện khác nhau, dễ dẫn đến lỗi và khó khăn trong việc bảo trì mã nguồn.
 
-- Người dùng có thể đăng ký nhận thông báo khi một sản phẩm nào đó có giá giảm.
+```mermaid
+graph LR
+    A[Ứng dụng Thương mại điện tử] -->|Cập nhật thông tin| B[Trang chủ]
+    A -->|Cập nhật thông tin| C[Trang chi tiết sản phẩm]
+    A -->|Cập nhật thông tin| D[Trang quản lý hàng tồn kho]
+```
 
-- Khi giá sản phẩm thay đổi, tất cả người dùng đã đăng ký sẽ nhận được thông báo.
+### Giải pháp
 
-Làm thế nào để triển khai khi có hàng triệu người dùng cùng theo dõi hàng triệu sản phẩm khác nhau?
+Observer Pattern giải quyết vấn đề trên bằng cách tạo ra một cơ chế "đăng ký - thông báo". Trong hệ thống, các thành phần có thể "đăng ký" để theo dõi trạng thái của một đối tượng. Khi có thay đổi trạng thái, đối tượng này sẽ tự động "thông báo" cho tất cả các thành phần đã đăng ký. Trở lại ví dụ về ứng dụng thương mại điện tử, thông tin sản phẩm sẽ là đối tượng "quan sát", và các giao diện như trang chủ, trang chi tiết sản phẩm sẽ là các "quản sát viên". Khi thông tin sản phẩm thay đổi, chỉ cần cập nhật một lần tại nguồn, và tất cả các giao diện liên quan sẽ được tự động cập nhật.
 
-## Giải quyết
+Việc sử dụng Observer Pattern mang lại nhiều lợi ích: giảm sự phụ thuộc lẫn nhau giữa các thành phần của hệ thống, tăng khả năng tái sử dụng và bảo trì mã nguồn. Hơn nữa, pattern này cũng cải thiện hiệu suất bằng cách giảm bớt số lượng cập nhật không cần thiết và chỉ tập trung vào những thay đổi có ý nghĩa.
 
-Observer Pattern được áp dụng như sau:
+Tuy nhiên, việc sử dụng Observer Pattern cũng đòi hỏi sự cân nhắc. Khi số lượng quan sát viên tăng lên, việc quản lý và debug có thể trở nên phức tạp. Ngoài ra, nếu không được thiết kế cẩn thận, pattern này có thể dẫn đến các vấn đề về hiệu suất do việc thông báo quá nhiều lần.
 
-- Định nghĩa một Subject (đối tượng chủ đề) đại diện cho sản phẩm.
+#### Sơ đồ minh họa
+```mermaid
+graph LR
+    A[Thông tin sản phẩm] -->|Thông báo thay đổi| B[Trang chủ]
+    A -->|Thông báo thay đổi| C[Trang chi tiết sản phẩm]
+    A -->|Thông báo thay đổi| D[Trang quản lý hàng tồn]
 
-- Người dùng (Observer) có thể đăng ký theo dõi Subject.
-
-- Khi trạng thái của Subject thay đổi (giá sản phẩm) thì sẽ thông báo tới tất cả Observer đã đăng ký.
-
-![](https://refactoring.guru/images/patterns/diagrams/observer/structure.png)
+ kho]
+    B -->|Đăng ký quan sát| A
+    C -->|Đăng ký quan sát| A
+    D -->|Đăng ký quan sát| A
+```
 
 ## Cấu trúc
 
diff --git a/docs/Book/Struct.md b/docs/Book/Struct.md
index 1fbbda2..fa5eaa1 100644
--- a/docs/Book/Struct.md
+++ b/docs/Book/Struct.md
@@ -15,6 +15,7 @@
 - **Cách tiếp cận**: Pattern giải quyết những vấn đề đã nêu trong phần "Vấn đề" như thế nào.
 - **Lợi ích**: Những ưu điểm khi sử dụng pattern.
 - **Sự đánh đổi**: Bất kỳ sự thỏa hiệp hoặc chi phí nào liên quan trong việc thực hiện pattern.
+- **Sơ đồ minh hoạ**: Cho sơ đồng minh hoạ đươc vẻ bằng mermaid.
 
 ### Cấu trúc (1-2 đoạn, 1 sơ đồ)