Tại sao sử dụng sự kiện tùy chỉnh thay vì gọi phương thức trực tiếp?

Question

Tôi là người mới lập trình và tôi đã kiểm tra rất nhiều hướng dẫn mã hóa trò chơi. Tôi đã nhận thấy rằng trên hầu hết trong số họ họ sử dụng các sự kiện tùy chỉnh để kích hoạt các phương thức thay vì gọi một phương thức trực tiếp.

Lý do đằng sau thực tiễn này là gì? Tại sao họ không gọi phương thức này?

Ví dụ:

---

Chúng tôi có hai đối tượng: A và B. A có phương thức A.methodA() rằng B cần sử dụng khi điều kiện X được kích hoạt.

Tại sao thực hiện:

B công văn một sự kiện để A mà nói A để chạy A.methodA()

Thay vì:

B sử dụng A.methodA()

Answer 1

Lý do chính là tách sở thích. Khi sử dụng các sự kiện, lớp A không cần biết về sự tồn tại của lớp B (và ngược lại).

Một số lợi ích này là:

• kiểm tra đơn vị Dễ dàng hơn nhiều (bạn có thể kiểm tra Class A mà không cần lớp B)
• Ít cơ hội phá vỡ mã của bạn khi bạn thay đổi lớp A hoặc B
• Less tham chiếu đến các lớp khác trong mã của bạn, làm giảm khả năng rò rỉ bộ nhớ
• Mã sạch
• Mã linh hoạt/có thể tái sử dụng được (tất cả các lớp khác đều có thể nghe/phản hồi sự kiện bất kỳ mã bổ sung nào trong điều phối viên của bạn)

Answer 2

Thông thường trong các ứng dụng lớn hơn sử dụng các sự kiện sẽ giúp trừu tượng mọi thứ. Khi bạn có hơn 15 lớp và tất cả đều là sự kiện ditpatching cho bộ điều khiển, sẽ dễ dàng hơn nhiều để tìm ra những gì đang xảy ra hơn là đọc qua tất cả các phần khác nhau của mã để theo dõi các hàm. Sử dụng gọi lại bắt đầu tạo mã spaghetti.

Tuy nhiên, các cuộc gọi hàm trực tiếp sẽ được thực thi nhanh hơn các sự kiện.

Answer 3

Cá nhân, tôi sử dụng các sự kiện tùy chỉnh để dễ sử dụng. Tôi có thể yêu cầu một lớp gửi một sự kiện khi có điều gì đó xảy ra (nói hoạt ảnh kết thúc hoặc lỗi xảy ra khi tải xuống) và bất kỳ số lượng lớp nào khác chạy bất kỳ số lượng chức năng nào khác dựa trên sự kiện đó. Ngoài ra, tôi viết mã cho khả năng sử dụng lại. Mục tiêu của mỗi lớp là hoàn toàn độc lập để nó có thể chạy trong bất kỳ dự án nào mà không cần các gói khác. Vì vậy, thay vì có một lớp gọi một phương thức của lớp khác, tôi gửi một sự kiện từ lớp đầu tiên mà lớp thứ hai lắng nghe và sau đó chạy phương thức đó. Sau đó, khi tôi cần lớp đầu tiên cho một dự án khác, tôi chỉ có thể sao chép/dán nó mà không cần phải sửa đổi nó và không mất bất kỳ chức năng nào.

EDIT: Ngoài ra, cần lưu ý rằng đôi khi mọi người làm những gì bạn mô tả để vượt qua phải vượt qua trong các đối số sự kiện.

Giả sử bạn có nút trên sân khấu và bạn cần có thể nhấp vào nút đó, nhưng bạn cũng cần phải có thể gọi phương thức đó theo cách thủ công. Một số người không nhận ra bạn có thể vượt qua trong một sự kiện null và chỉ có phương pháp duy nhất. Hoặc bạn có thể đặt nó làm đối số mặc định rỗng, xem bên dưới:

private function onClickHandler(e:MouseEvent = null):void{ 
    //as long as you never reference "e" within this method, this method can be used both for MouseEvent listeners and manually calling it elsewhere in the code 
} 

Kỹ thuật đó có thể giúp tránh trình xử lý sự kiện chỉ gọi phương thức khác và không có gì khác. Tại thời điểm này trong lập trình của tôi, mọi trình xử lý sự kiện AS3 đơn lẻ mà tôi viết đặt đối số sự kiện thành null theo mặc định. Nó chỉ làm cho mọi thứ dễ dàng hơn sau này.

Answer 4

You might want to read this.

Và cũng lưu ý sử dụng phương pháp gọi lại cho phép bạn truyền tham số cho nó trực tiếp và không qua một mô hình sự kiện tùy chỉnh.

Answer 5

Tôi đã xây dựng hệ thống điều phối sự kiện của riêng mình, rất đơn giản hóa. Mô hình sự kiện AS rất mạnh mẽ, nhưng trong 99% tình huống bạn không cần sức mạnh đó. Một cuộc gọi lại đơn giản với các tham số được kích hoạt như một sự kiện là quá đủ. Bạn vẫn có thể giữ lại tính linh hoạt từ một mô hình sự kiện, nhưng không cần phải viết quá nhiều dòng mã, ví dụ, một nút đơn giản. tôi có thể thiết lập một sự kiện đơn giản như thế này:

Buttonizer.autoButton(_buttQuit, this, "onPress"); 
public function onPressQuit(c:Sprite) { 
// Execution goes here 
} 

Bạn có thể xây dựng mô hình sự kiện của riêng bạn, nó sẽ làm cho cuộc sống đơn giản hơn, và mã của bạn nhiều hơn nữa súc tích.