O Observer está obsoleto no Java 9. O que devemos usar em vez dele?


Respostas:


104

Por que é que? Isso significa que não devemos mais implementar o padrão de observador?

Respondendo a última parte primeiro -

SIM , isso não significa que você não deve implementarObservereObervableé mais.

Por que eles foram reprovados -

Eles não forneceram um modelo de evento suficientemente rico para aplicativos. Por exemplo, eles poderiam apoiar apenas a noção de que algo mudou, mas não transmitiram nenhuma informação sobre o que mudou.

A resposta de Alex coloca bem à frente o que Observertem uma fraqueza: todos Observablesão iguais . É necessário implementar a lógica que se baseia instanceofe converter o objeto em tipo concreto no Observable.update()método.

Para adicionar a ele, havia erros como não se pode serializar aObservable classe porque, por não implementar a Serializableinterface e todos os seus membros serem privados.

Qual é a melhor alternativa para isso?

Por outro lado, Listenersexistem muitos tipos, métodos de retorno de chamada e não requerem conversão. Como apontado por @Ravi em sua resposta, você pode usar PropertyChangeListener.

No restante, @Deprecationfoi marcado com a documentação adequada para explorar outros pacotes, como também vinculados em outras respostas.


Observe que a descontinuação também foi marcada com uma análise, conforme declarado neste e-mail -

Atualmente, qualquer pessoa que os encontre provavelmente os encontrará por engano enquanto estiver usando RxJavaou outras estruturas de fluxo reativo. Nesse caso, os usuários normalmente desejam usar as java.util.concurrent.FlowAPIs do jdk9 para que todas as estruturas de fluxos reativos sejam compatíveis / interoperáveis ​​nas próximas versões compatíveis do jdk9 planejadas.

Edit : Também vale a pena mencionar que a descontinuação das APIs não se deve principalmente ao motivo acima, mas também a incapacidade de manter o código herdado mencionado nos comentários de alguns dos relatórios de erros (vinculados acima) que foram aumentados para marcar uma melhoria em sua implementação de uma ou de outra maneira.


3
+1. Boa resposta, embora eu ainda esteja tentando entender. O Observer em Java está obsoleto por causa de algum problema inerente ao próprio padrão de design (conforme definido no livro pelo GOF) ou pelo problema do suporte ao padrão por Java? Em outras linguagens OO, como C #, C ++, Python, o padrão de design do observador também tem o mesmo problema que em Java?
Tim

25
O fato de uma implementação específica estar obsoleta não significa que o padrão Observador seja fatalmente defeituoso. Listenertambém é um observador.
chrylis -cautiouslyoptimistic-

@chrylis Obrigado, não posso concordar mais, um dos principais motivos para descontinuar a API também é a manutenção associada a ela e que a alteração de sua implementação poderia estar quebrando outro código.
Naman

@ curious95 Não é possível entender a maneira de notificar o concorrente lá.
Naman

4
@ curious95 Sim, a chamada notifyObservers()é simultânea. Aqui está um codelet do mesmo compartilhado para explicar sua funcionalidade em detalhes.
Naman

37

Sim, está obsoleto no Java 9 . E não podemos mais implementar o padrão de observador.


Por que é que?

Há mais razões:

Não serializável - Como o Observable não implementa serializável. Portanto, você não pode Serialize Observable nem sua subclasse.

Sem segurança de encadeamento - Os métodos podem ser substituídos por suas subclasses e a notificação de eventos pode ocorrer em ordens diferentes e possivelmente em encadeamentos diferentes, o que é suficiente para interromper qualquer "segurança de encadeamento".

Menos a oferecer -

Eles não fornecem um modelo de evento suficientemente rico para aplicativos. Por exemplo, eles apóiam apenas a noção de que algo mudou, mas não transmitem nenhuma informação sobre o que mudou.

Questões em aberto - Como mencionado, muitos dos principais problemas foram levantados (segurança de encadeamento, serializável) e a maioria deles possuía complexidades a serem corrigidas e ainda "não consertadas" ou sem desenvolvimento ativo , e é por esse motivo que ela foi descontinuada .

Eu também recomendaria ler esta resposta Por que o padrão de observador deve ser reprovado? , @Jeff explicou outras razões para a desvalorização.


Então, qual é a alternativa que temos?

Você pode usar PropertyChangeEvente PropertyChangeListenerdo java.beanspacote.


PropertyChangeListenersubstitui Observer, mas o que devo estender / implementar no lugar de Observable?
LastStar007

Atualização: acho que a abordagem é adicionar uma PropertyChangeSupportvariável de instância, mas eu gostaria de receber uma confirmação.
LastStar007

3
@ LastStar007 Acho que você está certo. Encontrei um exemplo de código no Baeldung.com que faz exatamente isso.
Dragos Stanciu 22/11

13

Por que o Observer está obsoleto no Java 9?

Resp: A Observableclasse e a Observerinterface foram descontinuadas no Java 9 porque o modelo de evento suportado Observere Observableé bastante limitado, a ordem das notificações entregues peloObservable não é especificada e as alterações de estado não estão em correspondência um por um com as notificações.

Consulte o documento Java https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html

Alternativa do padrão Observer?

Existem muitas alternativas do padrão de design do Observer e o Reactive Streams é uma delas.

Fluxos reativos ou API de fluxo :

Flowé uma classe introduzida no Java 9 e tem 4 interfaces inter-relacionados: Processor, Publisher, Subscribere Subscription.

Flow.Processor : Um componente que atua como Assinante e Publicador.

Flow.Publisher : Um produtor de itens recebidos pelos Assinantes.

Flow.Subscriber : Um receptor de mensagens.

Flow.Subscription: Controle de mensagem vinculando a Flow.Publishere Flow.Subscriber.

Consulte o documento Java https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html


7

Considerando que a Observableclasse e a Observerinterface foram descontinuadas a partir do Java 9. De acordo com o post Observador e Observável do Java Desaprovado no JDK 9

O modelo de evento suportado pelo Observer e Observable é bastante limitado, a ordem das notificações entregues pelo Observable não é especificada e as alterações de estado não estão na correspondência individual com as notificações. Para um modelo de evento mais rico, considere usar o java.beans pacote. Para mensagens confiáveis ​​e ordenadas entre threads, considere usar uma das estruturas de dados simultâneas no java.util.concurrentpacote. Para programação do estilo de fluxos reativos, consulte a API Flow.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.