Mẫu quan sát sử dụng cơ chế kéo


10

Tôi đã tự hỏi về việc thực hiện sau đây của

public void update(Observable obs, Object arg)

trong khi tôi muốn gửi cho tất cả người quan sát của mình và cập nhật bằng notifyObserver()I và chuyển một tài liệu tham khảo cho thisngười quan sát có thể sử dụng getterstừ chủ đề để lấy thông tin anh ta muốn.

Là gì argtranh luận về phương pháp cập nhật có nghĩa là gì?


@RBT arglà một tham số hoặc nhóm tham số, dưới dạng tùy chọn bổ sung
umlcat

Câu trả lời:


11

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 getphương thức cụ thể của lớp về chủ đề này. Thật tệ. B- làm cho Observablegiao diện cụ thể hơn về lớp, đưa ra các getphươ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 heightcủ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 Observablegiao diện cụ thể hơn , cung cấp các phương thức truy cập cụ thể hơn. Ví dụ AgeObservablecung 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ể Observervà 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ả AgeObserverchỉ cần đơn giản là agecủ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 HeightObservercầ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.


Cảm ơn bạn đã giải thích này. Đối với câu hỏi của tôi, như bạn đã nói trong khi sử dụng pull, tôi cần phải bỏ cast và sử dụng getters, nhưng đối số trong phương pháp cập nhật quan sát là gì? - cập nhật khoảng trống công khai (Observable obs, Object arg)?
USer22999299

Tôi không chắc chắn, nhưng tôi nghĩ rằng Object argnó có nghĩa là cho mô hình 'đẩy', nơi argmột 'gói thông tin' được gửi đến người quan sát.
Manila Cohn

Vâng, đây là những gì tôi đã suy nghĩ, nhưng sau đó tại sao chúng ta gửi quan sát? :) nếu chúng ta bỏ cast, chúng ta có thể lấy thông tin mà chúng ta cần.
USer22999299

1
Bạn đang nói về 'đẩy' hay 'kéo'? Ý tưởng trong 'đẩy' là người quan sát không cần biết về loại đối tượng. Vì vậy, bạn tránh đúc xuống. Đúc xuống chủ yếu là xấu vì nó tạo ra sự liên kết chặt chẽ hơn giữa hai bên - người quan sát bây giờ biết loại chính xác của đối tượng, đánh bại toàn bộ mục đích. Nếu sau này một lớp mới thực hiện Observablegiao diện thì sao? Nếu bạn không dựa vào loại cụ thể của chủ đề - tức là bằng cách không thực hiện xuống - mã người quan sát hiện tại sẽ hoạt động tốt, đa hình, với chủ đề mới.
Manila Cohn

1
Nếu mã người quan sát của bạn dựa vào việc truyền xuống, nó sẽ cần thay đổi với mỗi lớp mới thực hiện giao diện Quan sát, do đó đánh bại toàn bộ mục đích của mẫu. Đây là một ví dụ về lý do tại sao 'lập trình cho giao diện, chứ không phải triển khai cụ thể' là một điều tốt - mã hoạt động trên giao diện sẽ hoạt động không thay đổi với mọi lớp mới thực hiện giao diện. Nếu bạn dựa vào việc triển khai cụ thể - ví dụ bằng cách thực hiện downcasting, mã của bạn sẽ cần thay đổi với mỗi lớp có thể quan sát mới. Đánh bại toàn bộ mục đích.
Manila Cohn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.