基於接口的回調/事件是否曾用於代理？

Question

在Java中，沒有委托，事件將在觀察者模式之后使用接口回調進行建模。 令我感到震驚的是，如果在一個有六個以上事件的框架上工作，使用代表就會變得相當冗長。

作為一個忘記了他的C＃的Java開發人員，我想知道是否有一個有效的理由使用接口進行事件，或者是否應該真的應該全部使用代理？

Answer 1

如果對多個回調做出反應總是有意義的，那么使用一個接口就可能有意義。 但是，您可能希望編寫一些適配器方法，以通過為某些回調提供委托來實現該接口，而這些委托只是您想要的那些。

這就是Reactive Extensions的工作方式......幾乎沒有人真正實現IObserver<T> - 它們使用IObservable<T>.Subscribe擴展方法，允許調用者通過委托指定OnNext ， OnCompleted和OnError處理程序。

這樣你就可以獲得委托的好處（由於lambda表達式等，通常比接口更容易指定），而且還有一個一致的對象傳遞，代表所有相關的回調。

Answer 2

代表們更靈活。 由於C＃中沒有匿名類（在Java意義上），因此無法輕松實現內聯接口。 因此，每當API要求我實現一個接口時，我都必須走出去並寫出該類，與lambda相比，它迫使我在物理上使邏輯彼此分開，這經常會降低可讀性。