2016-01-20 7 views
1

Я реализую десериализатор байтового сообщения, который будет отправлять десериализованные сообщения на интерфейс диспетчера и возвращать наблюдаемые из всех Throwable сбрасываемых, чтобы клиентский код мог обрабатывать ошибки.Создание объекта

Эскиз прототипа способа сделать это:

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

Теперь, как в последнее время я знаком с Subject<T, R>, который будет соответствовать здесь отлично, например,

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

Но нет удобных метод, таких как create(), которые могли бы легко делегировать для наблюдателя и наблюдаемого. Все конкретные реализации объединяют T с R, поэтому я не могу использовать один из них.

Так что мой конкретный вопрос: есть ли способ создать экземпляр подходящего Subject<byte[], Throwable>, который делегирует Observer и Observable? Есть ли другой способ создать такой Subject без необходимости реализовать (в смысле необходимости делегировать каждый реализованный метод вручную) все Subject, Observable и Observer?

+0

Вы могли бы найти преимущество в том, чтобы обернуть свой 'byte []' в классе, возможно, названный 'DeserializedMessage' или такой? –

+0

Не совсем, я бы назвал это недостатком. Если я правильно понимаю, вы предлагаете передать шаг декодирования в метод, создающий 'DeserializedMessage' из' byte [] 'chunks. Я бы предпочел остаться с двойным/гостевым кодированием (вызовите 'onTypeOfMessage()' на диспетчере), потому что он решает нужную часть (тип-безопасные расширяемые инструменты) проблемы выражения для нас. –

+1

YMMV, но я просто ненавижу прохождение примитивных типов, потому что неизменно кажется, что что-то меняется, и у вас нет места для маневра. –

ответ

2

Переключение на API на основе темы может быть не лучшей идеей, потому что вы меняете потенциально холодный API в обязательный горячий API. В вашем первоначальном дизайне потребитель последовательности Throwable будет принимать, когда он подписывается, также получает подписку на .

В противном случае у меня есть blog series о создании Subject s, но вы не можете избежать тяжелой работы с ними.

 Смежные вопросы

  • Нет связанных вопросов^_^