Là chuỗi sự kiện được coi là thực hành tốt?

Thỉnh thoảng tôi gặp phải các tình huống trong đó cần phải đáp ứng một số điều kiện phức tạp trước khi kích hoạt một sự kiện. Hơn nữa, hầu hết người nghe cũng chạy kiểm tra bổ sung để xác định quá trình hành động. Điều này khiến tôi suy nghĩ liệu một giải pháp tốt hơn sẽ là suy nghĩ theo các sự kiện nhỏ hơn và để chúng kích hoạt bên trong nhau.

Các sự kiện xâu chuỗi sẽ cho phép tôi tạo ra bất kỳ người nghe bổ sung nào sau này với nỗ lực khá thấp (có thể vi phạm YAGNI?). Mã của tôi sẽ bao gồm các yếu tố đơn giản dễ hiểu, không khó để người khác hiểu.

Tuy nhiên, nhược điểm có thể có của giải pháp này là thực tế là nếu có sự cố xảy ra trong chuỗi (ví dụ: kích hoạt sự kiện sai do lỗi của con người), sẽ rất khó để bắt lỗi.

Là sự kiện xâu chuỗi một ý tưởng tốt ^TM ? Nếu không, các phương pháp thay thế để giữ cho mã liên quan đến sự kiện bị lộn xộn là gì?

Sự kiện là một ý tưởng tốt?

Đó là một trong những điều có vẻ như là một ý tưởng thực sự tốt, cho đến khi bạn sử dụng nó.

Rất khó để thiết lập các sự kiện xếp tầng mà không có một số loại phụ thuộc ngụ ý theo thứ tự. Thật khó để thiết lập chúng mà không gây ra sự cố do các vòng lặp vô hạn và rò rỉ bộ nhớ không thường xuyên. Chúng làm cho thiết kế lớp trở nên khó khăn hơn do khớp nối gây ra bởi các sự kiện cần biết cả nơi để gắn và nơi để xếp tầng.

Và họ cực kỳ khó khăn trong việc gỡ lỗi và suy luận về mã.

Bây giờ đôi khi chúng có thể được sử dụng trong các kịch bản tương đối hạn chế trong đó cấu trúc của mã giới hạn một số vấn đề này. Trong UI, các sự kiện xếp tầng có thể được sử dụng để kích hoạt phân cấp vì cấu trúc phân cấp đó giúp hạn chế quyền sở hữu và lặp lại mối quan tâm.

Tuy nhiên, tôi thấy ngày nay tôi thường xuyên chấp nhận một đại biểu trong một nhà xây dựng cho loại hành vi có thể mở rộng đó hơn là để hành vi tùy tiện chốt lại trong thời gian chạy.

Chuỗi sự kiện là một ý tưởng tốt nếu

• Nó thường phù hợp với kịch bản của bạn. Một ví dụ đơn giản là hành động UI của người dùng kích hoạt các sự kiện hình ảnh khác.
• Mỗi sự kiện là khép kín và quản lý. Bạn không muốn giải pháp trở nên quá cồng kềnh.
• Dòng chảy của kiểm soát là dễ dàng để làm theo. Nó cần được triển khai trên một nền tảng và bằng ngôn ngữ mà nhà phát triển dễ dàng thực hiện. Nếu bạn cần theo dõi các phương pháp "ma thuật" để theo dõi những gì đang xảy ra, bạn đang đi sai đường.

Điều rất quan trọng là suy nghĩ giải pháp thông qua và khái quát hóa một số điều trước khi bắt đầu xây dựng hệ thống. Ví dụ, trong ngôn ngữ OO, bạn nên có một giao diện cơ bản hoặc lớp trừu tượng làm cơ sở cho tất cả các sự kiện. Lớp đó nên kết hợp những thứ như đăng nhập / gỡ lỗi. Bạn cũng có thể muốn một lớp quản lý sự kiện tổng quát để xử lý các lỗi một cách duyên dáng.

Phát biểu từ quan điểm của một người đã dành vài ngày để theo dõi một lỗi liên quan đến chuỗi sự kiện, đây là một ý tưởng rất tồi (sm). Bạn đang che giấu luồng kiểm soát của mình (như bạn đã lưu ý) có thể khiến việc gỡ lỗi trở thành một cơn ác mộng. Tình huống tôi đã phát sinh khi ai đó thêm một số mã xử lý lỗi để thiết lập lại điều khiển. Điều này dẫn đến một chuỗi các onPropertyChangetrình xử lý giúp làm mới điều khiển có trình xử lý lỗi, dẫn đến việc đặt lại điều khiển khác một lần nữa, v.v. Về cơ bản, giao diện người dùng chỉ cần khóa với CPU được chốt ở mức 100%.

Nếu bạn có một số cách để ngăn các trình xử lý sự kiện không được kích hoạt nhiều lần cho cùng một sự kiện gốc, thì bạn có thể tránh điều này, nhưng tôi có thể tưởng tượng các tình huống mà bạn có thể muốn có nhiều lệnh xử lý sự kiện.

Thực hiện chuỗi sự kiện tốt là khó khăn, vì tất cả các lý do được đề cập bởi những người khác.

Tuy nhiên, nó cũng là tiền đề cơ bản của hầu hết các công cụ quy tắc. JBoss Drools, IBM jRules, PegaSystems, Corticon và FICO Blaze Advisor đều là các Hệ thống quản lý quy tắc kinh doanh chính (BRMS) cho phép người dùng khai báo các quy tắc phát sinh dựa trên các sự kiện xảy ra trong hệ thống. Cả chuỗi tiến và lùi đều có thể và có thể thực hiện được.

Ngôn ngữ Prolog và các dẫn xuất của nó dựa trên cùng một khái niệm.

Các thuật toán liên quan không đơn giản, gỡ lỗi CÓ THỂ là một nỗi đau, nhưng có rất nhiều giá trị được tìm thấy trong mô hình.

Một nhược điểm tiềm năng là khá dễ dàng để vô tình kết thúc với các cập nhật lặp. ví dụ: A -> B -> C -> A -> B ...

Một cách tiếp cận khác là tạo ra các sự kiện tổng hợp chịu trách nhiệm bắn ra một chuỗi các sự kiện. Điều này có nghĩa là bạn không nên bị mắc kẹt trong một vòng lặp và cung cấp cho bạn một nơi duy nhất để bắt lỗi / v.v. Tôi đã có một số thành công với điều này, mặc dù phải thừa nhận rằng đã không sử dụng nó cho bất kỳ điều gì đặc biệt phức tạp (chưa!).