Ưu điểm của việc bơm xe buýt sự kiện Otto thay vì sử dụng ổ đơn tĩnh

Question

Trong các ứng dụng Android của tôi, tôi đang sử dụng Otto làm bus sự kiện và Dagger để tiêm phụ thuộc.

Trong hướng dẫn sử dụng Otto và trong nhiều bài đăng trên blog, bạn nên sử dụng tiêm để có được một chiếc xe buýt đơn. Tôi đã làm điều đó một thời gian, nhưng gần đây tôi đang nhận được nhiều nghi ngờ nếu tiêm xe buýt có bất kỳ lợi thế hơn bằng cách sử dụng một singleton tĩnh đơn giản.

Với việc tiêm, tôi phải tiêm mọi Chế độ xem hoặc Chế độ xem tùy chỉnh mà tôi muốn có thể đăng sự kiện giao diện người dùng trên xe buýt. Đặc biệt là với dao găm có vẻ hơi vụng về để tiêm mọi lớp mà tôi cần xe buýt. Chắc chắn, tôi có thể vượt qua xe buýt bằng cách xây dựng hoặc phương pháp setter, nhưng đó có thể là loại vụng về quá nếu bạn nghĩ về một bộ chuyển đổi với nhiều loại xem khác nhau ví dụ.

Và tôi không thấy bất kỳ ưu điểm nào khi tiêm bus. Trong trường hợp của Otto, việc thực hiện cụ thể được tiêm (một thể hiện của Bus) và điều đó sẽ không bao giờ thay đổi. Gói Otto cho de-coupling không có ý nghĩa gì nếu nghĩ, vì cách thức hoạt động của đăng ký.

Vì vậy, có ai thấy bất kỳ lợi thế nào khi tiêm Otto mà tôi không thấy không?

Answer 1

Theo ý kiến ​​của tôi, bạn chắc chắn nên bọc xe buýt sự kiện trong lớp học của riêng bạn và sử dụng kỹ thuật tiêm phụ thuộc để truyền nó cho khách hàng.

Có rất nhiều lợi thế để tiếp cận này trên chỉ đơn giản là có được một tài liệu tham khảo thông qua một cuộc gọi đến getInstance() phương pháp tĩnh:

• phụ thuộc của bạn trở nên rõ ràng. Khi bạn nhận được các tham chiếu đến các đối tượng thông qua các cuộc gọi tĩnh, các phụ thuộc được ẩn bên trong việc thực hiện các máy khách, điều này làm cho mã trở nên mong manh và khó hiểu hơn.
• Sẽ dễ dàng hơn khi chuyển sang triển khai khác của xe buýt sự kiện nếu cần.
• Phụ thuộc tiêm được dễ dàng hơn để thử nghiệm trong các thử nghiệm
• Thực tế là kỹ thuật tiêm phụ thuộc giới thiệu mức độ đấu tranh thực sự là một điều tốt - nếu bạn đang gặp khó khăn, điều này thường là một dấu hiệu cho thấy bạn đang làm điều gì sai. Trong trường hợp của bạn, tôi nghi ngờ rằng bạn đang lạm dụng xe buýt sự kiện.

Tôi nói rằng có thể bạn đang lạm dụng xe buýt sự kiện vì tôi không thực sự hiểu tại sao bạn cần phải tham chiếu đến nó trong các lớp con View. Tôi đoán rằng bạn đăng thông báo về tương tác của người dùng với xe buýt sự kiện và sau đó đăng ký Activity hoặc Fragment tới xe buýt sự kiện để chặn các sự kiện này. Bus sự kiện là một công cụ sai trong trường hợp này (mặc dù nó hoạt động tốt).

Lý do tại sao xe buýt sự kiện là công cụ sai trong trường hợp này là do Fragments và Activity có thể có quyền truy cập trực tiếp vào các đối tượng có chứa View. Bạn có thể tham khảo các số điện thoại Views này và đăng ký Fragments và Activities làm người nghe. Không cần phải decouple bất cứ điều gì ở đây.

Ngược lại: suy nghĩ về trường hợp bạn đi và cấu trúc lại Views theo cách không có gì được đăng lên xe buýt sự kiện nữa (yêu cầu thay đổi doanh nghiệp).Vì thông báo Views chỉ được kết hợp lỏng lẻo để chứa Fragment hoặc Activity thông qua xe buýt sự kiện, rất có thể bạn sẽ quên xóa logic xử lý sự kiện khỏi Fragment và Activity, do đó để lại "mã chết". Điều này rất lộn xộn.

Việc thực hành tốt hơn sẽ được sử dụng mẫu thiết kế Observer và để Views thông báo Activities và Fragments trực tiếp, và chỉ khi xử lý liên quan đến một thành phần (mà không thể dễ dàng đạt từ Fragment và Activity; ví dụ khác Fragment hoặc Activity) sẽ các thành phần này đăng sự kiện lên xe buýt sự kiện. Nếu bạn làm theo cách tiếp cận này, bạn sẽ cần phải có một tham chiếu đến xe buýt sự kiện trong "thành phần cấp cao nhất" chỉ, và không có đấu tranh sẽ được tham gia.

P.S. Gần đây, tôi đã xuất bản một số blog post which introduces some best practices for dependency injection in Android.