:) Supongo que ya ha renunciado a seguir leyendo nuestras divagaciones :-)

Yo creo que al final es muy similar. EventBus incluye en la propia librería un singleton (más bien una clase estática) al que se llama cuando hay que notificar.
Guava argumenta que, aunque usar un punto global de acceso mediante singleton sería el patrón más común, pretende dar libertad al desarrollador para decidir como lo usa.
https://code.google.com/p/guava-libraries/wiki/EventBusExplained
FAQ:
"Why must I create my own Event Bus, rather than using a singleton?"

En mi ejemplo tonto hago un new, pero perfectamente podriamos hacer una clase estática o singleton que proporcione la funcionalidad, o como planteo en el comentario del código, inyectar cuando lo necesitemos.

Un saludo,

... Y todo esto cuando a @germymcg le podíamos haber dicho simplemente que haga el método setLabel de tipo public y static y lo llame desde el otro frame...

;-)

Guenas.

Yo no se vosotros, pero yo cuando tengo sidrales como estos lo que suelo hacer es un modelo único que implementa tropecientos interfaces modelo y cada view accede a su parte. Al ser modelo unico (si, los fire... me los tengo que currar, pero creo que vale la pena).
Hasta ahora me ha ido bien y es bastante claro. Un modelo no tiene porque subscribir un solo interfaz modelo. Los datos son únicos, su visión es variable.

Quizá haya acoplación o no, pero hasta ahora me ha ido de puta madre.
Mi info, en general, es única y permite tantas vistas como modelos particulares. En cualquier caso es única y no tengo que copiar ni transmitir nada.

Acepto y deseo discusión al respecto :)

Un saludo

Buenas,

Entiendo que cuando hablas de un modelo unico te refieres a que tienes un solo POJO inmenso, con 300 campos, que implementa 50 interfaces. Esas interfaces proveen cada una de una vista parcial del modelo, que es con la que trabajas.

Aunque me parece un poco extrano, yo no tengo nada que objectar o discutir, sobre todo si dices que te va bien con ese sistema :-). No obstante, no le veo mucha ventaja.
Que beneficio aporta tener un superPOJO y 50 interfaces sobre tener 50 POJOs? Yo veo mas clara y facil de manejar la segunda opcion...

Un saludo

Guenas.

Efectivamente, pero no es tan grande. Al final los métodos comunes de la mayor parte de interfaces tienen la misma funcion con lo que no tengo mas que llamar a un método único para tratarlos.

Es muy cierto que tener distintas implementaciones para cada particularidad me modularizan el código, pero a cambio, cuando tengo un cambio que afecta a 30 de las 50 particularizaciones solo tengo que hacer un cambio en lugar de 30. Esto es lo que me ha ocurrido mas veces y por ello digo que me ha salido a cuenta.

De todos modos estamos hablando de casos extremos. En general suelo usar beans propios no excesivamente complicados que vía eventos modifican un modelo comun.

No creo que haya ninguna necesidad de crear tropecientos modelos simplones que se comuniquen entre ellos cuando el tema a modelar es complejo. Puedo crear sus interfaces simples e implementarlas en un modelo comun. El modelo creo que debe modelar la realidad. Si esta es compleja el modelo será complejo, aunque lo separe internamente en submodelos simples, pero eso si, sobre los mismos datos.

Un saludo

Gracias a todos por sus respuestas. Lo resolvi de creando una variable "intancia" que apuntaba al frame y accedi a ella por la clase.

Declare la variable
public static JFrame1 instancia;

En el constructor:
instancia = this;

Y en el otro frame.
String txt=JFrame1.instancia.jLabel.getText(); por ejemplo