Observer Pattern ด้วย JavaScript WeakRef: สร้างระบบอีเวนต์ที่จัดการหน่วยความจำอย่างมีประสิทธิภาพ

ในโลกของการพัฒนาเว็บสมัยใหม่ Single Page Applications (SPAs) ได้กลายเป็นมาตรฐานสำหรับการสร้างประสบการณ์ผู้ใช้ที่ไดนามิกและตอบสนองได้ดี แอปพลิเคชันเหล่านี้มักจะทำงานเป็นระยะเวลานาน จัดการสถานะที่ซับซ้อน และรองรับการโต้ตอบของผู้ใช้นับไม่ถ้วน อย่างไรก็ตาม ความสามารถในการทำงานที่ยาวนานนี้มาพร้อมกับต้นทุนแฝง นั่นคือความเสี่ยงที่เพิ่มขึ้นของ memory leak (หน่วยความจำรั่วไหล) ซึ่งเป็นภาวะที่แอปพลิเคชันยังคงยึดครองหน่วยความจำที่ไม่ต้องการอีกต่อไป สิ่งนี้สามารถลดประสิทธิภาพการทำงานลงเมื่อเวลาผ่านไป นำไปสู่ความเชื่องช้า เบราว์เซอร์ล่ม และประสบการณ์ผู้ใช้ที่แย่ หนึ่งในสาเหตุที่พบบ่อยที่สุดของการรั่วไหลเหล่านี้อยู่ในรูปแบบการออกแบบพื้นฐาน นั่นคือ Observer pattern

Observer pattern เป็นรากฐานสำคัญของสถาปัตยกรรมที่ขับเคลื่อนด้วยอีเวนต์ (event-driven architecture) ซึ่งช่วยให้อ็อบเจกต์ (observers) สามารถสมัครรับข้อมูลและรับการอัปเดตจากอ็อบเจกต์ส่วนกลาง (subject) ได้ มันเป็นรูปแบบที่สวยงาม เรียบง่าย และมีประโยชน์อย่างยิ่ง แต่การนำไปใช้แบบดั้งเดิมมีข้อบกพร่องที่สำคัญคือ subject จะเก็บการอ้างอิงแบบ strong reference ไปยัง observer ของมัน หาก observer ไม่เป็นที่ต้องการของส่วนอื่น ๆ ในแอปพลิเคชันอีกต่อไป แต่นักพัฒนาลืมที่จะยกเลิกการสมัคร (unsubscribe) อย่างชัดเจน มันจะไม่ถูก garbage collected เลย มันจะยังคงติดอยู่ในหน่วยความจำเหมือนผีที่คอยหลอกหลอนประสิทธิภาพของแอปพลิเคชันของคุณ

นี่คือจุดที่ JavaScript สมัยใหม่ พร้อมด้วยฟีเจอร์จาก ECMAScript 2021 (ES12) ได้มอบโซลูชันที่ทรงพลัง ด้วยการใช้ประโยชน์จาก WeakRef และ FinalizationRegistry เราสามารถสร้าง Observer pattern ที่ตระหนักถึงหน่วยความจำซึ่งจะล้างข้อมูลของตัวเองโดยอัตโนมัติ ป้องกันการรั่วไหลที่พบบ่อยเหล่านี้ บทความนี้เป็นการเจาะลึกเทคนิคขั้นสูงนี้ เราจะสำรวจปัญหา ทำความเข้าใจเครื่องมือ สร้างการใช้งานที่แข็งแกร่งตั้งแต่ต้น และอภิปรายว่าควรนำรูปแบบที่ทรงพลังนี้ไปใช้เมื่อใดและที่ไหนในแอปพลิเคชันระดับโลกของคุณ

ทำความเข้าใจปัญหาหลัก: Observer Pattern แบบดั้งเดิมและผลกระทบต่อหน่วยความจำ

ก่อนที่เราจะชื่นชมโซลูชัน เราต้องเข้าใจปัญหาอย่างถ่องแท้ Observer pattern หรือที่เรียกว่า Publisher-Subscriber pattern ถูกออกแบบมาเพื่อลดการพึ่งพากันระหว่างคอมโพเนนต์ Subject (หรือ Publisher) จะดูแลรายการของอ็อบเจกต์ที่ขึ้นอยู่กับมัน ซึ่งเรียกว่า Observers (หรือ Subscribers) เมื่อสถานะของ Subject เปลี่ยนแปลง มันจะแจ้งเตือน Observers ทั้งหมดโดยอัตโนมัติ โดยทั่วไปจะเรียกใช้เมธอดเฉพาะบนตัว Observers เช่น update()

ลองดูการใช้งานแบบคลาสสิกที่เรียบง่ายใน JavaScript

การสร้าง Subject แบบง่าย

นี่คือคลาส Subject พื้นฐาน มีเมธอดสำหรับสมัคร (subscribe) ยกเลิกการสมัคร (unsubscribe) และแจ้งเตือน (notify) observers

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} ได้สมัครรับข้อมูลแล้ว`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} ได้ยกเลิกการสมัครแล้ว`);

  }

 

  notify(data) {

    console.log('กำลังแจ้งเตือน observers...');

    this.observers.forEach(observer => observer.update(data));

  }

}

และนี่คือคลาส Observer แบบง่ายที่สามารถสมัครรับข้อมูลจาก Subject ได้

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} ได้รับข้อมูล: ${data}`);

  }

}

อันตรายที่ซ่อนอยู่: การอ้างอิงที่ค้างอยู่

การใช้งานนี้ทำงานได้ดีตราบใดที่เราจัดการวงจรชีวิตของ observers ของเราอย่างขยันขันแข็ง ปัญหาจะเกิดขึ้นเมื่อเราไม่ทำเช่นนั้น ลองพิจารณาสถานการณ์ทั่วไปในแอปพลิเคชันขนาดใหญ่: ที่เก็บข้อมูลส่วนกลางที่มีอายุการใช้งานยาวนาน (Subject) และคอมโพเนนต์ UI ชั่วคราว (Observer) ที่แสดงข้อมูลบางส่วนนั้น

ลองจำลองสถานการณ์นี้:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // คอมโพเนนต์ทำงานของมัน...

 

  // ตอนนี้ ผู้ใช้ไปยังหน้าอื่น และคอมโพเนนต์นี้ไม่เป็นที่ต้องการอีกต่อไป

  // นักพัฒนาอาจลืมเพิ่มโค้ดสำหรับล้างข้อมูล:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // เราปล่อยการอ้างอิงไปยังคอมโพเนนต์

}

 

manageUIComponent();

 

// ในภายหลังของวงจรชีวิตแอปพลิเคชัน...

dataStore.notify('มีข้อมูลใหม่!');

ในฟังก์ชัน `manageUIComponent` เราสร้าง `chartComponent` และสมัครรับข้อมูลกับ `dataStore` ของเรา ต่อมา เราตั้งค่า `chartComponent` เป็น `null` เพื่อส่งสัญญาณว่าเราใช้งานมันเสร็จแล้ว เราคาดหวังว่า garbage collector (GC) ของ JavaScript จะเห็นว่าไม่มีการอ้างอิงถึงอ็อบเจกต์นี้อีกต่อไปและจะเรียกคืนหน่วยความจำของมัน

แต่ยังมีการอ้างอิงอีกหนึ่งที่! อาร์เรย์ `dataStore.observers` ยังคงมีการอ้างอิงโดยตรงแบบ strong reference ไปยังอ็อบเจกต์ `chartComponent` อยู่ เนื่องจากการอ้างอิงที่ค้างอยู่นี้เพียงจุดเดียว ทำให้ garbage collector ไม่สามารถเรียกคืนหน่วยความจำได้ อ็อบเจกต์ `chartComponent` และทรัพยากรใด ๆ ที่มันถืออยู่ จะยังคงอยู่ในหน่วยความจำตลอดอายุการใช้งานของ `dataStore` หากสิ่งนี้เกิดขึ้นซ้ำ ๆ เช่น ทุกครั้งที่ผู้ใช้เปิดและปิดหน้าต่าง modal การใช้หน่วยความจำของแอปพลิเคชันจะเพิ่มขึ้นอย่างไม่มีที่สิ้นสุด นี่คือ memory leak แบบคลาสสิก

ความหวังใหม่: ขอแนะนำ WeakRef และ FinalizationRegistry

ECMAScript 2021 ได้นำเสนอสองฟีเจอร์ใหม่ที่ออกแบบมาโดยเฉพาะเพื่อจัดการกับความท้าทายในการจัดการหน่วยความจำประเภทนี้: `WeakRef` และ `FinalizationRegistry` พวกมันเป็นเครื่องมือขั้นสูงและควรใช้อย่างระมัดระวัง แต่สำหรับปัญหา Observer pattern ของเรา พวกมันคือโซลูชันที่สมบูรณ์แบบ

WeakRef คืออะไร?

อ็อบเจกต์ `WeakRef` เก็บการอ้างอิงแบบ weak reference ไปยังอ็อบเจกต์อื่น ซึ่งเรียกว่าเป้าหมาย (target) ของมัน ความแตกต่างที่สำคัญระหว่าง weak reference และการอ้างอิงปกติ (strong) คือ: weak reference จะไม่ขัดขวางอ็อบเจกต์เป้าหมายจากการถูก garbage collected

หากการอ้างอิงทั้งหมดไปยังอ็อบเจกต์เป็น weak references แล้ว JavaScript engine สามารถทำลายอ็อบเจกต์และเรียกคืนหน่วยความจำของมันได้ นี่คือสิ่งที่เราต้องการเพื่อแก้ปัญหา Observer ของเรา

ในการใช้ `WeakRef` คุณต้องสร้างอินสแตนซ์ของมัน โดยส่งอ็อบเจกต์เป้าหมายไปยัง constructor ในการเข้าถึงอ็อบเจกต์เป้าหมายในภายหลัง คุณจะใช้เมธอด `deref()`

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// ในการเข้าถึงอ็อบเจกต์:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`อ็อบเจกต์ยังคงอยู่: ${retrievedObject.id}`); // ผลลัพธ์: อ็อบเจกต์ยังคงอยู่: 42

} else {

  console.log('อ็อบเจกต์ถูก garbage collected ไปแล้ว');

}

ส่วนที่สำคัญคือ `deref()` สามารถคืนค่าเป็น `undefined` ได้ สิ่งนี้จะเกิดขึ้นหาก `targetObject` ถูก garbage collected ไปแล้วเนื่องจากไม่มี strong references ใด ๆ ไปยังมันอีกต่อไป พฤติกรรมนี้เป็นรากฐานของ Observer pattern ที่ตระหนักถึงหน่วยความจำของเรา

FinalizationRegistry คืออะไร?

ในขณะที่ `WeakRef` อนุญาตให้อ็อบเจกต์ถูกเก็บได้ แต่มันไม่ได้ให้วิธีที่สะอาดในการรู้ว่า เมื่อใด ที่มันถูกเก็บไปแล้ว เราอาจจะตรวจสอบ `deref()` เป็นระยะ ๆ และลบผลลัพธ์ที่เป็น `undefined` ออกจากรายการ observer ของเรา แต่นั่นไม่มีประสิทธิภาพ นี่คือจุดที่ `FinalizationRegistry` เข้ามามีบทบาท

A `FinalizationRegistry` ช่วยให้คุณลงทะเบียนฟังก์ชัน callback ที่จะถูกเรียกใช้ หลังจาก อ็อบเจกต์ที่ลงทะเบียนไว้ถูก garbage collected ไปแล้ว มันเป็นกลไกสำหรับการล้างข้อมูลหลังจากการทำลาย

นี่คือวิธีการทำงาน:

1. คุณสร้าง registry พร้อมกับ cleanup callback
2. คุณ `register()` อ็อบเจกต์กับ registry คุณยังสามารถระบุ `heldValue` ซึ่งเป็นข้อมูลที่จะถูกส่งไปยัง callback ของคุณเมื่ออ็อบเจกต์ถูกเก็บ `heldValue` นี้ต้องไม่ใช่การอ้างอิงโดยตรงไปยังตัวอ็อบเจกต์เอง เพราะนั่นจะทำลายวัตถุประสงค์!

// 1. สร้าง registry พร้อมกับ cleanup callback

const registry = new FinalizationRegistry(heldValue => {

  console.log(`มีอ็อบเจกต์ถูก garbage collected โทเค็นสำหรับล้างข้อมูล: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. ลงทะเบียนอ็อบเจกต์และระบุโทเค็นสำหรับการล้างข้อมูล

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack หลุดออกจาก scope ที่นี่

})();

 

// ณ จุดใดจุดหนึ่งในอนาคต หลังจาก GC ทำงาน คอนโซลจะแสดงข้อความ:

// "มีอ็อบเจกต์ถูก garbage collected โทเค็นสำหรับล้างข้อมูล: temp-data-123"

ข้อควรระวังและแนวทางปฏิบัติที่ดีที่สุด

ก่อนที่เราจะลงลึกถึงการใช้งาน สิ่งสำคัญคือต้องเข้าใจธรรมชาติของเครื่องมือเหล่านี้ พฤติกรรมของ garbage collector ขึ้นอยู่กับการใช้งานของแต่ละ engine และไม่สามารถคาดเดาได้ (non-deterministic) ซึ่งหมายความว่า:

• คุณ ไม่สามารถ คาดเดาได้ว่าอ็อบเจกต์จะถูกเก็บเมื่อใด อาจเป็นวินาที นาที หรือนานกว่านั้นหลังจากที่มันไม่สามารถเข้าถึงได้
• คุณ ไม่สามารถ พึ่งพา callback ของ `FinalizationRegistry` ให้ทำงานในเวลาที่เหมาะสมหรือคาดเดาได้ พวกมันมีไว้สำหรับการล้างข้อมูล ไม่ใช่สำหรับตรรกะที่สำคัญของแอปพลิเคชัน
• การใช้ `WeakRef` และ `FinalizationRegistry` มากเกินไปอาจทำให้โค้ดเข้าใจยากขึ้น ควรเลือกใช้วิธีแก้ปัญหาที่ง่ายกว่าเสมอ (เช่น การเรียก `unsubscribe` อย่างชัดเจน) หากวงจรชีวิตของอ็อบเจกต์นั้นชัดเจนและจัดการได้

ฟีเจอร์เหล่านี้เหมาะที่สุดสำหรับสถานการณ์ที่วงจรชีวิตของอ็อบเจกต์หนึ่ง (observer) เป็นอิสระอย่างแท้จริงและไม่เป็นที่รู้จักของอีกอ็อบเจกต์หนึ่ง (subject)

การสร้าง `WeakRefObserver` Pattern: การสร้างทีละขั้นตอน

ตอนนี้ เราจะรวม `WeakRef` และ `FinalizationRegistry` เข้าด้วยกันเพื่อสร้างคลาส `WeakRefSubject` ที่ปลอดภัยต่อหน่วยความจำ

ขั้นตอนที่ 1: โครงสร้างคลาส `WeakRefSubject`

คลาสใหม่ของเราจะเก็บ `WeakRef`s ไปยัง observers แทนการอ้างอิงโดยตรง และยังมี `FinalizationRegistry` เพื่อจัดการการล้างรายการ observers โดยอัตโนมัติ

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // ใช้ Set เพื่อให้ลบได้ง่ายขึ้น

 

    // finalizer callback จะได้รับค่า held value ที่เราให้ไว้ตอนลงทะเบียน

    // ในกรณีของเรา held value จะเป็นอินสแตนซ์ของ WeakRef เอง

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: มี observer ถูก garbage collected กำลังล้างข้อมูล...');

      this.observers.delete(weakRefObserver);

    });

  }

}

เราใช้ `Set` แทน `Array` สำหรับรายการ observers ของเรา เพราะการลบรายการออกจาก `Set` มีประสิทธิภาพมากกว่ามาก (ความซับซ้อนของเวลาเฉลี่ย O(1)) เมื่อเทียบกับการกรอง `Array` (O(n)) ซึ่งจะมีประโยชน์ในตรรกะการล้างข้อมูลของเรา

ขั้นตอนที่ 2: เมธอด `subscribe`

เมธอด `subscribe` คือจุดที่เวทมนตร์เริ่มต้นขึ้น เมื่อ observer สมัครรับข้อมูล เราจะ:

1. สร้าง `WeakRef` ที่ชี้ไปยัง observer
2. เพิ่ม `WeakRef` นี้ลงใน `observers` set ของเรา
3. ลงทะเบียนอ็อบเจกต์ observer ตัวจริงกับ `FinalizationRegistry` ของเรา โดยใช้ `WeakRef` ที่สร้างขึ้นใหม่เป็น `heldValue`

// ภายในคลาส WeakRefSubject...

subscribe(observer) {

  // ตรวจสอบว่ามี observer ที่มีการอ้างอิงนี้อยู่แล้วหรือไม่

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Observer ได้สมัครรับข้อมูลไปแล้ว');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // ลงทะเบียนอ็อบเจกต์ observer ตัวจริง เมื่อมันถูกเก็บ,

  // finalizer จะถูกเรียกโดยมี `weakRefObserver` เป็นอาร์กิวเมนต์

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('มี observer ได้สมัครรับข้อมูลแล้ว');

}

การตั้งค่านี้สร้างวงจรที่ชาญฉลาด: subject เก็บ weak reference ไปยัง observer ส่วน registry เก็บ strong reference ไปยัง observer (ภายใน) จนกว่าจะถูก garbage collected เมื่อถูกเก็บแล้ว callback ของ registry จะถูกเรียกพร้อมกับอินสแตนซ์ของ weak reference ซึ่งเราสามารถใช้เพื่อล้าง `observers` set ของเราได้

ขั้นตอนที่ 3: เมธอด `unsubscribe`

แม้จะมีการล้างข้อมูลอัตโนมัติ เราก็ยังควรมีเมธอด `unsubscribe` แบบแมนนวลสำหรับกรณีที่ต้องการการลบที่คาดการณ์ได้ เมธอดนี้จะต้องค้นหา `WeakRef` ที่ถูกต้องใน set ของเราโดยการ dereference แต่ละตัวและเปรียบเทียบกับ observer ที่เราต้องการลบ

// ภายในคลาส WeakRefSubject...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // สำคัญ: เราต้องยกเลิกการลงทะเบียนจาก finalizer ด้วย

    // เพื่อป้องกันไม่ให้ callback ทำงานโดยไม่จำเป็นในภายหลัง

    this.cleanupRegistry.unregister(observer);

    console.log('มี observer ได้ยกเลิกการสมัครด้วยตนเองแล้ว');

  }

}

ขั้นตอนที่ 4: เมธอด `notify`

เมธอด `notify` จะวนซ้ำผ่าน set ของ `WeakRef`s ของเรา สำหรับแต่ละตัว มันจะพยายาม `deref()` เพื่อรับอ็อบเจกต์ observer ที่แท้จริง หาก `deref()` สำเร็จ หมายความว่า observer ยังคงอยู่ และเราสามารถเรียกเมธอด `update` ของมันได้ หากคืนค่าเป็น `undefined` แสดงว่า observer ถูกเก็บไปแล้ว และเราสามารถเพิกเฉยได้เลย `FinalizationRegistry` จะลบ `WeakRef` ของมันออกจาก set ในที่สุด

// ภายในคลาส WeakRefSubject...

notify(data) {

  console.log('กำลังแจ้งเตือน observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // observer ยังคงอยู่

      observer.update(data);

    } else {

      // observer ถูก garbage collected ไปแล้ว

      // FinalizationRegistry จะจัดการลบ weakRef นี้ออกจาก set

      console.log('พบการอ้างอิง observer ที่ตายแล้วระหว่างการแจ้งเตือน');

    }

  }

}

การนำทั้งหมดมารวมกัน: ตัวอย่างการใช้งานจริง

กลับมาที่สถานการณ์คอมโพเนนต์ UI ของเราอีกครั้ง แต่คราวนี้ใช้ `WeakRefSubject` ใหม่ของเรา เราจะใช้คลาส `Observer` เดียวกันกับก่อนหน้านี้เพื่อความเรียบง่าย

// คลาส Observer แบบง่ายตัวเดิม

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} ได้รับข้อมูล: ${data}`);

  }

}

ตอนนี้ ลองสร้างบริการข้อมูลส่วนกลางและจำลองวิดเจ็ต UI ชั่วคราว

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- กำลังสร้างและสมัครวิดเจ็ตใหม่ ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // ตอนนี้วิดเจ็ตทำงานอยู่และจะได้รับการแจ้งเตือน

  globalDataService.notify({ price: 100 });

 

  console.log('--- กำลังทำลายวิดเจ็ต (ปล่อยการอ้างอิงของเรา) ---');

  // เราใช้งานวิดเจ็ตเสร็จแล้ว เราตั้งค่าการอ้างอิงเป็น null

  // เราไม่จำเป็นต้องเรียก unsubscribe()

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- หลังจากการทำลายวิดเจ็ต, ก่อน garbage collection ---');

globalDataService.notify({ price: 105 });

หลังจากรัน `createAndDestroyWidget()` อ็อบเจกต์ `chartWidget` จะถูกอ้างอิงโดย `WeakRef` ภายใน `globalDataService` ของเราเท่านั้น เนื่องจากนี่เป็นการอ้างอิงแบบ weak reference อ็อบเจกต์จึงมีสิทธิ์ถูก garbage collection ได้แล้ว

เมื่อ garbage collector ทำงานในที่สุด (ซึ่งเราไม่สามารถคาดเดาได้) จะเกิดสองสิ่งขึ้น:

1. อ็อบเจกต์ `chartWidget` จะถูกลบออกจากหน่วยความจำ
2. callback ของ `FinalizationRegistry` ของเราจะถูกเรียกใช้ ซึ่งจะลบ `WeakRef` ที่ตายแล้วออกจาก `globalDataService.observers` set

หากเราเรียก `notify` อีกครั้งหลังจาก garbage collector ทำงาน การเรียก `deref()` จะคืนค่า `undefined`, observer ที่ตายแล้วจะถูกข้ามไป และแอปพลิเคชันจะทำงานต่อไปอย่างมีประสิทธิภาพโดยไม่มี memory leak เราได้แยกวงจรชีวิตของ observer ออกจาก subject ได้สำเร็จแล้ว

เมื่อใดควรใช้ (และเมื่อใดควรหลีกเลี่ยง) `WeakRefObserver` Pattern

รูปแบบนี้ทรงพลัง แต่ก็ไม่ใช่ยาวิเศษ มันเพิ่มความซับซ้อนและอาศัยพฤติกรรมที่ไม่สามารถคาดเดาได้ สิ่งสำคัญคือต้องรู้ว่าเมื่อใดที่มันเป็นเครื่องมือที่เหมาะสมกับงาน

กรณีการใช้งานในอุดมคติ

• Subject ที่มีอายุยืนยาวและ Observer ที่มีอายุสั้น: นี่คือกรณีการใช้งานหลัก บริการส่วนกลาง, ที่เก็บข้อมูล, หรือแคช (subject) ที่มีอยู่ตลอดวงจรชีวิตของแอปพลิเคชัน ในขณะที่คอมโพเนนต์ UI, worker ชั่วคราว, หรือปลั๊กอิน (observers) จำนวนมากถูกสร้างและทำลายบ่อยครั้ง
• กลไกการแคช: ลองนึกภาพแคชที่จับคู่อ็อบเจกต์ที่ซับซ้อนกับผลลัพธ์ที่คำนวณได้ คุณสามารถใช้ `WeakRef` สำหรับอ็อบเจกต์คีย์ได้ หากอ็อบเจกต์ดั้งเดิมถูก garbage collected จากส่วนอื่น ๆ ของแอปพลิเคชัน `FinalizationRegistry` สามารถล้างรายการที่สอดคล้องกันในแคชของคุณโดยอัตโนมัติ ป้องกันไม่ให้หน่วยความจำบวม
• สถาปัตยกรรมปลั๊กอินและส่วนขยาย: หากคุณกำลังสร้างระบบหลักที่อนุญาตให้โมดูลของบุคคลที่สามสมัครรับอีเวนต์ การใช้ `WeakRefObserver` จะเพิ่มชั้นของความยืดหยุ่น มันป้องกันไม่ให้ปลั๊กอินที่เขียนไม่ดีซึ่งลืม unsubscribe ก่อให้เกิด memory leak ในแอปพลิเคชันหลักของคุณ
• การจับคู่ข้อมูลกับ DOM Elements: ในสถานการณ์ที่ไม่มีเฟรมเวิร์กแบบ declarative คุณอาจต้องการเชื่อมโยงข้อมูลบางอย่างกับ DOM element หากคุณเก็บสิ่งนี้ไว้ใน map โดยมี DOM element เป็นคีย์ คุณอาจสร้าง memory leak ได้หาก element ถูกลบออกจาก DOM แต่ยังคงอยู่ใน map ของคุณ `WeakMap` เป็นตัวเลือกที่ดีกว่าในที่นี้ แต่หลักการเดียวกันคือ: วงจรชีวิตของข้อมูลควรผูกกับวงจรชีวิตของ element ไม่ใช่ในทางกลับกัน

เมื่อใดควรใช้ Observer แบบดั้งเดิม

• วงจรชีวิตที่ผูกกันอย่างแน่นหนา: หาก subject และ observers ของมันถูกสร้างและทำลายพร้อมกันหรือภายใน scope เดียวกันเสมอ ค่าใช้จ่ายและความซับซ้อนของ `WeakRef` ก็ไม่จำเป็น การเรียก `unsubscribe()` อย่างชัดเจนและง่าย ๆ จะอ่านง่ายและคาดเดาได้ง่ายกว่า
• เส้นทางการทำงานที่สำคัญต่อประสิทธิภาพ (Hot Paths): เมธอด `deref()` มีค่าใช้จ่ายด้านประสิทธิภาพเล็กน้อยแต่ก็ไม่ใช่ศูนย์ หากคุณกำลังแจ้งเตือน observers หลายพันตัวหลายร้อยครั้งต่อวินาที (เช่น ใน game loop หรือการแสดงภาพข้อมูลความถี่สูง) การใช้งานแบบคลาสสิกด้วยการอ้างอิงโดยตรงจะเร็วกว่า
• แอปพลิเคชันและสคริปต์ที่ไม่ซับซ้อน: สำหรับแอปพลิเคชันหรือสคริปต์ขนาดเล็กที่อายุการใช้งานสั้นและการจัดการหน่วยความจำไม่ใช่ข้อกังวลที่สำคัญ รูปแบบคลาสสิกนั้นง่ายต่อการนำไปใช้และทำความเข้าใจ อย่าเพิ่มความซับซ้อนในสิ่งที่ไม่จำเป็น
• เมื่อต้องการการล้างข้อมูลที่คาดการณ์ได้ (Deterministic): หากคุณต้องการดำเนินการบางอย่างในจังหวะที่ observer ถูกแยกออกพอดี (เช่น การอัปเดตตัวนับ, การปล่อยทรัพยากรฮาร์ดแวร์เฉพาะ) คุณต้องใช้เมธอด `unsubscribe()` แบบแมนนวล ลักษณะที่ไม่สามารถคาดเดาได้ของ `FinalizationRegistry` ทำให้ไม่เหมาะสำหรับตรรกะที่ต้องทำงานอย่างคาดการณ์ได้

ผลกระทบในวงกว้างต่อสถาปัตยกรรมซอฟต์แวร์

การนำ weak references เข้ามาในภาษาระดับสูงอย่าง JavaScript เป็นสัญญาณของวุฒิภาวะของแพลตฟอร์ม มันช่วยให้นักพัฒนาสามารถสร้างระบบที่ซับซ้อนและยืดหยุ่นมากขึ้น โดยเฉพาะสำหรับแอปพลิเคชันที่ทำงานเป็นเวลานาน รูปแบบนี้ส่งเสริมการเปลี่ยนแปลงในแนวคิดทางสถาปัตยกรรม:

• การแยกส่วนอย่างแท้จริง (True Decoupling): มันช่วยให้เกิดการแยกส่วนในระดับที่เหนือกว่าแค่ interface ตอนนี้เราสามารถแยก วงจรชีวิต ของคอมโพเนนต์ออกจากกันได้เลย subject ไม่จำเป็นต้องรู้อะไรเลยว่า observers ของมันถูกสร้างหรือทำลายเมื่อใด
• ความยืดหยุ่นโดยการออกแบบ (Resilience by Design): มันช่วยสร้างระบบที่ทนทานต่อข้อผิดพลาดของโปรแกรมเมอร์มากขึ้น การลืมเรียก `unsubscribe()` เป็นข้อผิดพลาดทั่วไปที่อาจติดตามได้ยาก รูปแบบนี้ช่วยลดข้อผิดพลาดประเภทนั้นทั้งประเภท
• การเสริมศักยภาพให้ผู้สร้างเฟรมเวิร์กและไลบรารี: สำหรับผู้ที่สร้างเฟรมเวิร์ก, ไลบรารี, หรือแพลตฟอร์มสำหรับนักพัฒนาคนอื่น ๆ เครื่องมือเหล่านี้มีค่าอย่างยิ่ง มันช่วยให้สามารถสร้าง API ที่แข็งแกร่งซึ่งมีความอ่อนไหวต่อการใช้งานในทางที่ผิดโดยผู้บริโภคไลบรารีน้อยลง นำไปสู่แอปพลิเคชันที่เสถียรยิ่งขึ้นโดยรวม

สรุป: เครื่องมืออันทรงพลังสำหรับนักพัฒนา JavaScript สมัยใหม่

Observer pattern แบบดั้งเดิมเป็นส่วนประกอบพื้นฐานของการออกแบบซอฟต์แวร์ แต่การพึ่งพา strong references ของมันเป็นสาเหตุของ memory leak ที่ละเอียดอ่อนและน่าหงุดหงิดในแอปพลิเคชัน JavaScript มายาวนาน ด้วยการมาถึงของ `WeakRef` และ `FinalizationRegistry` ใน ES2021 ตอนนี้เรามีเครื่องมือที่จะเอาชนะข้อจำกัดนี้ได้แล้ว

เราได้เดินทางจากการทำความเข้าใจปัญหาพื้นฐานของการอ้างอิงที่ค้างอยู่ไปสู่การสร้าง `WeakRefSubject` ที่ตระหนักถึงหน่วยความจำอย่างสมบูรณ์ตั้งแต่ต้น เราได้เห็นว่า `WeakRef` ช่วยให้อ็อบเจกต์สามารถถูก garbage collected ได้แม้ในขณะที่ถูก 'สังเกตการณ์' และ `FinalizationRegistry` ให้กลไกการล้างข้อมูลอัตโนมัติเพื่อรักษารายการ observer ของเราให้สะอาดอยู่เสมอ

อย่างไรก็ตาม พลังที่ยิ่งใหญ่มาพร้อมกับความรับผิดชอบที่ยิ่งใหญ่ นี่เป็นฟีเจอร์ขั้นสูงซึ่งมีลักษณะที่ไม่สามารถคาดเดาได้ซึ่งต้องพิจารณาอย่างรอบคอบ มันไม่ใช่สิ่งทดแทนการออกแบบแอปพลิเคชันที่ดีและการจัดการวงจรชีวิตที่ขยันขันแข็ง แต่เมื่อนำไปใช้กับปัญหาที่ถูกต้อง เช่น การจัดการการสื่อสารระหว่างบริการที่มีอายุยืนยาวและคอมโพเนนต์ชั่วคราว WeakRef Observer pattern เป็นเทคนิคที่ทรงพลังอย่างยิ่ง ด้วยการฝึกฝนจนเชี่ยวชาญ คุณจะสามารถเขียนแอปพลิเคชัน JavaScript ที่แข็งแกร่ง มีประสิทธิภาพ และปรับขนาดได้มากขึ้น พร้อมที่จะตอบสนองความต้องการของเว็บยุคใหม่ที่ไดนามิก