mẫu trình lắng nghe sự kiện trong api - những gì nên thêm cùng một người nghe hai lần làm gì?

Khi thiết kế API cung cấp giao diện nghe sự kiện, có vẻ như có hai cách xử lý các cuộc gọi để thêm / xóa người nghe:

1. Nhiều cuộc gọi đến addListener sẽ chỉ thêm một người nghe (như thêm nó vào một tập hợp); có thể được loại bỏ bằng một lệnh gọi đến removeListener.

2. Nhiều cuộc gọi đến addListener sẽ thêm một người nghe mỗi lần (như thêm nó vào danh sách); phải được cân bằng bởi nhiều lệnh gọi đến removeListener.

Tôi đã tìm thấy một ví dụ về mỗi: (1) - Cuộc gọi DOM addEventListener trong trình duyệt chỉ thêm người nghe một lần, âm thầm bỏ qua các yêu cầu để thêm cùng một người nghe lần thứ hai và (2) - .onHành vi jQuery thêm người nghe nhiều lần .

Hầu hết các API người nghe khác dường như sử dụng (2), chẳng hạn như trình nghe sự kiện SWT và Swing. Nếu (1) được chọn, cũng có câu hỏi liệu nó có nên thất bại âm thầm hay có lỗi khi có yêu cầu thêm cùng một người nghe hai lần.

Trong các triển khai của mình, tôi có xu hướng gắn bó với (2) vì nó cung cấp giao diện loại thiết lập / phá vỡ sạch hơn và phát hiện ra các lỗi trong đó "thiết lập" vô tình được thực hiện hai lần và phù hợp với hầu hết các triển khai tôi đã thấy.

Điều này dẫn tôi đến câu hỏi của tôi - Có một kiến ​​trúc cụ thể hoặc thiết kế cơ bản nào khác cho vay tốt hơn cho việc thực hiện khác không? (tức là: tại sao mô hình khác tồn tại?)

Nếu bạn gặp một số sự kiện mà bạn đang gặp vấn đề với việc quản lý thêm / xóa, tôi sẽ bắt đầu thêm ID.

Thêm một người nghe trả về một ID, lớp đã thêm nó theo dõi ID cho người nghe, nó đã được thêm vào và khi cần xóa chúng, nó sẽ xóa người nghe bằng / các ID duy nhất đó.

Điều này đặt người tiêu dùng vào tầm kiểm soát để họ có thể tuân thủ Nguyên tắc tối thiểu ngạc nhiên trong hành vi.

Điều này có nghĩa là thêm cùng một hai lần thêm hai lần, cung cấp một ID khác nhau cho mỗi ID và xóa bằng ID chỉ xóa một liên kết với ID đó. Bất cứ ai sử dụng API đều mong đợi hành vi này khi họ nhìn thấy các hạt cát.

Một sự bổ sung nữa khi vi phạm YAGNI sẽ là một GetIds nơi bạn trao cho người nghe và nó trả về một danh sách ID được liên kết với người nghe đó nếu nó có khả năng kiểm tra sự bình đẳng phù hợp, mặc dù điều đó phụ thuộc vào ngôn ngữ của bạn , loại bình đẳng, bình đẳng giá trị, vv? bạn phải cẩn thận ở đây vì bạn có thể trả lại ID mà người tiêu dùng không nên xóa hoặc can thiệp, do đó việc tiếp xúc này trở nên nguy hiểm và không được khuyến khích và không cần thiết, nhưng GetID là một chương trình bổ sung có thể nếu bạn cảm thấy may mắn.

Đầu tiên, tôi sẽ chọn một cách tiếp cận trong đó thứ tự mà người nghe được thêm vào chính xác là thứ tự họ sẽ được gọi khi các sự kiện liên quan được kích hoạt. Nếu bạn quyết định đi theo (1), điều đó có nghĩa là bạn sử dụng một bộ được đặt hàng, không chỉ là một bộ.

Thứ hai, bạn nên làm rõ mục tiêu thiết kế chung: API của bạn sẽ tuân theo chiến lược "sớm gặp sự cố" hay chiến lược "tha thứ lỗi"? Điều này phụ thuộc vào môi trường sử dụng và các tình huống sử dụng API của bạn. Nói chung, (phát triển chủ yếu các ứng dụng trên máy tính) Tôi thích "sập sớm", nhưng đôi khi tốt hơn là chịu đựng một số loại lỗi để giúp việc sử dụng API trơn tru hơn. Các yêu cầu, ví dụ, trong các ứng dụng nhúng hoặc ứng dụng máy chủ có thể khác nhau. Có lẽ bạn thảo luận điều này với một trong những người dùng API tiềm năng của bạn?

Đối với chiến lược "sụp đổ sớm", hãy sử dụng (2), nhưng cấm thêm cùng một người nghe hai lần, ném ngoại lệ nếu người nghe được thêm lại. Cũng ném một ngoại lệ nếu một người cố gắng loại bỏ một người nghe không có trong danh sách.

Nếu bạn nghĩ rằng chiến lược "tha thứ lỗi" phù hợp hơn trong trường hợp của bạn, bạn có thể

• bỏ qua việc thêm hai lần của cùng một người nghe vào danh sách - đó là tùy chọn (1) - hoặc

• nối nó vào danh sách như trong (2), vì vậy nó sẽ được gọi hai lần khi các sự kiện được kích hoạt

• hoặc bạn chắp thêm nó, nhưng đừng gọi cùng một người nghe hai lần trong trường hợp kích hoạt sự kiện

Lưu ý rằng việc loại bỏ người nghe phải tương ứng với điều đó - nếu bạn bỏ qua việc thêm hai lần, bạn cũng nên bỏ qua việc loại bỏ hai lần. Nếu bạn cho phép cùng một người nghe được thêm hai lần, thì rõ ràng mục nào trong hai mục nghe sẽ bị xóa khi một cuộc gọi removeListener(foo). Lần cuối cùng trong ba viên đạn có lẽ là cách tiếp cận ít bị lỗi nhất trong số những gợi ý đó, vì vậy trong trường hợp chiến lược "tha thứ lỗi", tôi sẽ thực hiện theo cách đó.