2016-01-20 102 views
1

我正在實現一個字節消息解串器,它將在調度器接口上調度反序列化的消息,並返回拋出的所有Throwable的可觀察值,以便客戶機代碼可以處理這些錯誤。創建主題

方法的原型的草圖這樣做:

Observable<Throwable> dispatchDeserializedMessages(Observable<byte[]>, Dispatcher) 

現在由於最近我所熟悉的Subject<T, R>,這將完全適合在這裏,如

Subject<byte[], Throwable> dispatchDeserializedMessages(Dispatcher) 

但沒有方便的方法,如create()這很容易授人以觀察員,可觀察到的。所有的具體實現統一TR,所以我沒辦法使用其中的一個。

所以我的具體問題:有沒有辦法可以實例化一個合適的Subject<byte[], Throwable>,它代表ObserverObservable?是否有任何其他方式可以創建這樣的Subject,而不必實施(在必須手動委託每個實施的方法的意義上)整個Subject,和Observer

+0

你是否會發現將'byte []'封裝在一個可能名爲'DeserializedMessage'或類似的類中的優點? –

+0

不是,我會說這是一個缺點。如果我理解正確,你建議將解碼步驟外包給一個方法,從'byte []'塊生成'DeserializedMessage's。我寧願留在現在使用dual/visitor編碼(在調度器上調用onTypeOfMessage()),因爲它解決了表達式問題所需的部分(類型安全的可擴展工具)。 –

+1

YMMV,但我只是討厭傳遞原始類型,因爲總是看起來有些變化,而且你沒有任何迴旋餘地。 –

回答

2

切換到基於主題的API可能不是最好的主意,因爲您將潛在的冷API更改爲強制熱API。在您的原始設計中,Throwable序列的使用者將假定其訂閱時,也會訂閱Observable<byte[]>

否則,我有一個blog series關於創建Subject s但你無法避免與他們沉重的舉重。