Khi triển khai mẫu Người quan sát, có hai cách tiếp cận chính cần xem xét: mô hình 'đẩy' và mô hình 'kéo'.
Trong mô hình 'đẩy', chủ thể (tức là có thể quan sát) sẽ gửi cho người quan sát thông báo tất cả dữ liệu cần thiết. Người quan sát không cần truy vấn chủ đề để biết thông tin. Trong mô hình 'kéo', chủ thể chỉ thông báo cho người quan sát rằng có gì đó đã xảy ra và người quan sát truy vấn đối tượng dựa trên để có được thông tin cần thiết.
Hãy thảo luận về ưu và nhược điểm của cả hai phương pháp:
Đẩy
Ưu điểm chính của mô hình 'đẩy' là khớp nối thấp hơn giữa người quan sát và chủ thể. Người quan sát không cần biết gì về chủ đề này để truy vấn nó. Nếu cần, chúng ta cần thực hiện một trong những điều sau đây: A- thực hiện việc bỏ qua phía người quan sát để gọi các get
phương thức cụ thể của lớp về chủ đề này. Thật tệ. B- làm cho Observable
giao diện cụ thể hơn về lớp, đưa ra các get
phương thức cụ thể , do đó làm cho mối quan hệ giữa người quan sát và chủ đề trở nên ít chung chung hơn và khiến mọi thứ trở nên phức tạp hơn.
Bằng cách thực hiện mô hình 'đẩy', chúng tôi tránh được tất cả những điều này.
Tuy nhiên, nhược điểm là kém linh hoạt: đối tượng có thể không phải lúc nào cũng biết thông tin chính xác mà người quan sát cần để gửi cho họ. Điều này thường có nghĩa là các không gian quan sát cụ thể hơn, chẳng hạn như AgeObserver
được thông báo khi 'tuổi' của chủ thể được thay đổi và HeightObserver
được gửi hiện tại height
của chủ đề trong thông báo.
Đây là một lựa chọn. Khác là chủ đề gửi toàn bộ rất nhiều thông tin được gói gọn trong một Info
đối tượng thuộc loại nào đó và có người quan sát truy vấn nó từ đó. Nhưng một lần nữa, chúng tôi không thể chắc chắn rằng chúng tôi đang gửi thông tin chính xác. Vì vậy, đây là hoặc buộc các nhà quan sát phải thực hiện các giao diện Observer cụ thể hơn, giúp thắt chặt khớp nối ở phía của người quan sát.
Kéo
Tôi đã lưu ý những nhược điểm của mô hình 'kéo'. Các nhà quan sát sẽ phải biết những điều về chủ đề này để truy vấn đúng thông tin, điều này dẫn đến việc A- bị hạ thấp (xấu xí), hoặc B- thuận lợi cho các Observable
giao diện cụ thể hơn , cung cấp các phương thức truy cập cụ thể hơn. Ví dụ AgeObservable
cung cấp một getAge()
phương pháp.
Ưu điểm của việc này là linh hoạt hơn. Mỗi người quan sát có thể tự quyết định những gì cần truy vấn, mà không cần dựa vào đối tượng để gửi thông tin chính xác.
Bạn nên chọn chiến lược tốt hơn cho dự án cụ thể mà bạn đang thực hiện.
Trong thực tế, bạn sẽ luôn có các không gian cụ thể Observer
và cụ thể Observable
, vì vậy dù sao bạn cũng có một số khớp nối giữa các bên.
Vì vậy, chọn 'kéo' hoặc 'đẩy' theo những gì phù hợp nhất với bạn.
Có phải tất cả AgeObserver
chỉ cần đơn giản là age
của chủ đề? Thực hiện mô hình 'đẩy'. Ít khớp nối và đơn giản hơn.
Có phải tất cả đều HeightObserver
cần thông tin khác nhau về chủ đề - aka người ta cũng cần truy vấn độ tuổi và một số đối tượng khác cần truy vấn trọng số ngoài chiều cao? Thực hiện mô hình 'kéo'. Điều này sẽ buộc bạn phải thêm các bộ truy cập (getters) vào vùng bên trong Observable
(điều này hoặc truyền đối tượng thực tế làm tham số trong loại rõ ràng của nó, nhưng thực hiện điều này thông qua giao diện cho phép bạn từ chối người quan sát truy cập vào những thứ không quan trọng họ). Linh hồn này tạo ra khớp nối cao hơn, nhưng nó linh hoạt hơn.
Chọn những gì phù hợp với tình huống của bạn tốt nhất.
arg
là một tham số hoặc nhóm tham số, dưới dạng tùy chọn bổ sung