Olá pessoal,
Sempre que implementei uma aplicação java com MVC utilizei a classe Observer do java, contanto muito se vê por ai de implementações de observer feitas no braço, ou seja, não usam a api do java para fazer essa implementação, assim criam listas que ao chamar o notify (ou update) percorem essas lista avisando todos os objetos.
Então fiquei na duvida porque eles não usam a API ? Ela tem algum problema ou limitação ?
[quote=gustavo_l_walker]Olá pessoal,
Sempre que implementei uma aplicação java com MVC utilizei a classe Observer do java, contanto muito se vê por ai de implementações de observer feitas no braço, ou seja, não usam a api do java para fazer essa implementação, assim criam listas que ao chamar o notify (ou update) percorem essas lista avisando todos os objetos.
Então fiquei na duvida porque eles não usam a API ? Ela tem algum problema ou limitação ?
[/quote]
A API do java é para ser usada pelas outras api do java como jmx e swing.
No dia a dia vc pode criar seu próprio mecanismo de observer.
Sergio não entendi pq essa API deveria ser usada somente pelas API do próprio JAVA e não ser usada para desenvolvimento de aplicações?
Uso o observer da API em aplicações e nunca tive problema, eu acho melhor do que reinventar a roda, a matéria do Sergio ta mais pra uso de Listeners, e algo diferente do Observer padrão do java, mas cuidado o Observer da API pode ser alvo para Dependencias Circulares.
Primeiro que tudo o padrão listener não tem um proposito difernete da API do Observer. Ambos servem para responder a eventos. A diferença está no como. A API de Observable é baseada em herança e isso é sempre ruim. Claro que vc pode usar por composição, mas dá tanto ou mais trabalho que usar listener. Por outro lado, os listeners recebem eventos (objetos fortemente tipados) e é isso que dá vantagem. Tanto é que EventObject foi adicionado no java 1.1 e é a base dos eventos AWT. O conceito de orientação a eventos é mais lato que simplesmente o padrão observer, da mesma forma que o MVC.
Em MVC se usa orientação a eventos e por isso se usa mecanismos com listeners que recebem objetos de evento.
A diferença está nas razões tecnicas e boas práticas vs más práticas e não no padrão Observer em si.
porque é muito comum usar o mecanismo de observers e porque usar herança é ruim, o artigo que mostrei explora como encapsular o codigo repetitivo e chato de uma implementação de listeners.
Respondendo diretamente: a api padrão tem limitações e viola várias boas práticas. Estas limitações são resolvidas pelo mecanismo de listeners que são baseados em práticas melhores ( na realidade listenens usam o padrão observer + padrão context object)
Sergio,
No seu exemplo eu não consegui entender qual seria a implementação do BagEvent
[quote=gustavo_l_walker]Sergio,
No seu exemplo eu não consegui entender qual seria a implementação do BagEvent[/quote]
O BagEvent é o objeto de evento. Ele é o que os BagListeners recebem do Bag.
Nesse objeto estão as informações relativas ao evento. Estas informações podem ser várias.
Por exemplo, no caso, o evento de adicionar é distinto do remover na interface do listener, mas poderia ser apenas um parametros do objeto evento (o que em geral é uma má práticas, mas existem situações onde é aceite). No caso , o evento é disparado quando um elemento é adicionado ou removido do Bag, portanto o atributo obvio seria o elemento que foi removido ou adicionado.
No mundo real os objetos de evento podem ser variados e até ter ciclos de vida complexos como os eventos do AWT.
O propósito de usar um objeto e não passar os atributos 1 a 1 é diminuir o acoplamento, permitindo adicionar novos atributos sem modificar as interfaces dos listener. Os eventos de evento , eles mesmos, seguem o padrão Context Object.
Concordo com o Taborda, sempre fiz o padrão no braço. Não mata a única herança disponível e analizando o algoritmo parece ser favorável.
Bastante conteúdo sobre MVC poderá ser encontrado aqui!
Tanto teoria quanto implementação! Tem uma parte onde o Observer é discutido.
Espero ter ajudado! 
Olá pessoal, segue link com exemplo de Observer JSE:
http://www.patternizando.com.br/2011/03/design-pattern-observer-com-aplicacao-swing-jse/