Design Pattern | Observer Pattern
Hãy tưởng tượng bạn có một blog yêu thích. Mỗi ngày, bạn truy cập vào nó nhiều lần để kiểm tra các bài đăng blog mới, sau một thời gian, bạn ngán với thói quen này. Bạn nghĩ phải có một cách tốt hơn cho chính mình, giải pháp đầu tiên trong đầu bạn là viết một kịch bản để kiểm tra các bài đăng mới mỗi giây. Nhưng khi xem xét thêm, bạn sẽ thấy rằng hầu hết các trang web sẽ không đánh giá cao hàng loạt yêu cầu của bạn và sẽ chặn IP của bạn như thể bạn là mối nguy hiểm cho một đợt tấn công từ chối dịch vụ của họ thay vì là một độc giả yêu thích.
Để tránh điều này, thay vào đó, bạn viết một kịch bản để kiểm tra các bài đăng với mỗi giờ một lần. Nhưng phải chấp nhận một sự thất vọng, điều này có nghĩa là bạn đang phải bỏ các bài đăng cung cấp các thay đổi trực tiếp, chẳng hạn như các bài đăng live về chương trình yêu thích của bạn, một giải pháp tốt hơn cho bạn là để blog thông báo cho bạn mỗi khi bài viết mới được thêm vào, bạn sẽ nhấn nút đăng ký blog, mỗi khi bài đăng mới được xuất bản, blog sẽ thông báo cho mỗi người đăng ký, bao gồm cả bạn. Bằng cách này, bạn sẽ thông báo về mọi nội dung mới khi nó được tạo, thay vì phải lấy thông tin này trong một khoảng thời gian.
Chủ đề trong ví dụ của chúng ta, blog, sẽ giữ một danh sách các nhà quan sát (observer), các nhà quan sát dựa vào blog để thông báo cho họ về bất kỳ thay đổi nào đối với trạng thái của blog, chẳng hạn như khi một bài đăng blog mới được thêm vào. Trước khi chúng ta chính thức hóa mẫu này, hãy khám phá cách chúng ta có thể áp dụng ý tưởng này cho ví dụ của mình.
Trước tiên, chúng ta sẽ có một superclass chủ đề (Subjext superclass) xác định ba phương thức, cho phép người quan sát mới đăng ký, cho phép người quan sát hiện tại hủy đăng ký, và thông báo cho tất cả người quan sát về một bài đăng blog mới. Superclass này cũng sẽ có thuộc tính để theo dõi tất cả các quan sát viên và sẽ tạo giao diện quan sát (Observer interface) với các phương thức mà một người quan sát có thể được thông báo để tự cập nhật. Tiếp theo, lớp blog, sẽ là một lớp con của Subject class, và Subcriber class sẽ triển khai Observer interface. Các yếu tố này rất cần thiết để hình thành mối quan hệ Subject (chủ thể) + Observer (người quan sát). Ví dụ, đối với blog và người đăng ký, trong sơ đồ trình tự áp dụng mẫu quan sát viên, có hai quy tắc chính là Chủ thể và Người quan sát, Người đăng ký phải đăng ký vào blog, tiếp theo, blog cần có thông báo cho người đăng ký của mình rằng một sự thay đổi đã xảy ra. Đó là công việc của chức năng thông báo để giữ cho tất cả các thuê bao nhất quán.
Phương thức này chỉ được gọi khi blog có sự thay đổi sẵn sàng cho người đăng ký biết. Sau khi blog có thay đổi, đã đến lúc blog thông báo cho người dùng của mình thông qua cuộc gọi cập nhật và người đăng ký nhận trạng thái của blog thông qua lần gọi nhận trạng thái. Nếu người đăng ký không quan tâm nữa, họ sẽ cần một cách để hủy đăng ký. Đó là lần gọi cuối cùng trong sơ đồ trình tự, nó bắt nguồn từ người đăng ký và cho phép blog biết người đăng ký nên bị xóa khỏi danh sách người đăng ký. Đây là hành vi cốt lõi của Observer Pattern.
Hãy xem ý tưởng này có thể được trừu tượng hóa thành một mẫu thiết kế như thế nào, qua sơ đồ UML sau đây:
Trong sơ đồ, superclass Subject có ba phương thức, đăng ký, không đăng ký, và thông báo. Đây là tất cả những điều cần thiết cho quan sát viên của nó. Cụ thể, subclass blog sẽ kế thừa các phương thức này để đăng ký, hủy đăng ký và thông báo cho người đăng ký. Giao diện quan sát chỉ có phương thức cập nhật, (update()), lớp Subcriber implement giao diên Observer, cung cấp phần thân của phương thức cập nhật để người đăng ký có thể nhận được những gì thay đổi trong blog. Lưu ý rằng một chủ để có thể có 0 hoặc nhiều người quan sát đã đăng ký với nó tại bất kỳ thời điểm nào.
Chúng ta sẽ xem code cho superclass Object sẽ trông như thế nào, khá đơn giản, không có gì để nói luôn.
Lớp blog là extends của lớp Subject.
Bây giờ, sẽ đến Observer Interface, đảm bảo tất cả các đối tượng quan sát hành xử theo cùng một cách, các lớp observer chỉ thực hiện một phương thức duy nhất, cập nhật. Phương thức update() được gọi bởi subject, đối tượng đảm bảo khi thay đổi xảy ra, tất cả các quan sát viên của nó được thông báo để tự cập nhật.
Observer Pattern có thể giúp bạn tiết kiệm nhiều thời gian để triển khai hệ thống của mình.
Cảm ơn.
Để tránh điều này, thay vào đó, bạn viết một kịch bản để kiểm tra các bài đăng với mỗi giờ một lần. Nhưng phải chấp nhận một sự thất vọng, điều này có nghĩa là bạn đang phải bỏ các bài đăng cung cấp các thay đổi trực tiếp, chẳng hạn như các bài đăng live về chương trình yêu thích của bạn, một giải pháp tốt hơn cho bạn là để blog thông báo cho bạn mỗi khi bài viết mới được thêm vào, bạn sẽ nhấn nút đăng ký blog, mỗi khi bài đăng mới được xuất bản, blog sẽ thông báo cho mỗi người đăng ký, bao gồm cả bạn. Bằng cách này, bạn sẽ thông báo về mọi nội dung mới khi nó được tạo, thay vì phải lấy thông tin này trong một khoảng thời gian.
Chủ đề trong ví dụ của chúng ta, blog, sẽ giữ một danh sách các nhà quan sát (observer), các nhà quan sát dựa vào blog để thông báo cho họ về bất kỳ thay đổi nào đối với trạng thái của blog, chẳng hạn như khi một bài đăng blog mới được thêm vào. Trước khi chúng ta chính thức hóa mẫu này, hãy khám phá cách chúng ta có thể áp dụng ý tưởng này cho ví dụ của mình.
Trước tiên, chúng ta sẽ có một superclass chủ đề (Subjext superclass) xác định ba phương thức, cho phép người quan sát mới đăng ký, cho phép người quan sát hiện tại hủy đăng ký, và thông báo cho tất cả người quan sát về một bài đăng blog mới. Superclass này cũng sẽ có thuộc tính để theo dõi tất cả các quan sát viên và sẽ tạo giao diện quan sát (Observer interface) với các phương thức mà một người quan sát có thể được thông báo để tự cập nhật. Tiếp theo, lớp blog, sẽ là một lớp con của Subject class, và Subcriber class sẽ triển khai Observer interface. Các yếu tố này rất cần thiết để hình thành mối quan hệ Subject (chủ thể) + Observer (người quan sát). Ví dụ, đối với blog và người đăng ký, trong sơ đồ trình tự áp dụng mẫu quan sát viên, có hai quy tắc chính là Chủ thể và Người quan sát, Người đăng ký phải đăng ký vào blog, tiếp theo, blog cần có thông báo cho người đăng ký của mình rằng một sự thay đổi đã xảy ra. Đó là công việc của chức năng thông báo để giữ cho tất cả các thuê bao nhất quán.
Phương thức này chỉ được gọi khi blog có sự thay đổi sẵn sàng cho người đăng ký biết. Sau khi blog có thay đổi, đã đến lúc blog thông báo cho người dùng của mình thông qua cuộc gọi cập nhật và người đăng ký nhận trạng thái của blog thông qua lần gọi nhận trạng thái. Nếu người đăng ký không quan tâm nữa, họ sẽ cần một cách để hủy đăng ký. Đó là lần gọi cuối cùng trong sơ đồ trình tự, nó bắt nguồn từ người đăng ký và cho phép blog biết người đăng ký nên bị xóa khỏi danh sách người đăng ký. Đây là hành vi cốt lõi của Observer Pattern.
Hãy xem ý tưởng này có thể được trừu tượng hóa thành một mẫu thiết kế như thế nào, qua sơ đồ UML sau đây:
Trong sơ đồ, superclass Subject có ba phương thức, đăng ký, không đăng ký, và thông báo. Đây là tất cả những điều cần thiết cho quan sát viên của nó. Cụ thể, subclass blog sẽ kế thừa các phương thức này để đăng ký, hủy đăng ký và thông báo cho người đăng ký. Giao diện quan sát chỉ có phương thức cập nhật, (update()), lớp Subcriber implement giao diên Observer, cung cấp phần thân của phương thức cập nhật để người đăng ký có thể nhận được những gì thay đổi trong blog. Lưu ý rằng một chủ để có thể có 0 hoặc nhiều người quan sát đã đăng ký với nó tại bất kỳ thời điểm nào.
Chúng ta sẽ xem code cho superclass Object sẽ trông như thế nào, khá đơn giản, không có gì để nói luôn.
Lớp blog là extends của lớp Subject.
Bây giờ, sẽ đến Observer Interface, đảm bảo tất cả các đối tượng quan sát hành xử theo cùng một cách, các lớp observer chỉ thực hiện một phương thức duy nhất, cập nhật. Phương thức update() được gọi bởi subject, đối tượng đảm bảo khi thay đổi xảy ra, tất cả các quan sát viên của nó được thông báo để tự cập nhật.
Nhận xét
Đăng nhận xét