Setar Informação JFrame anterior

Estou fazendo um Gerenciado de Futebol. Eu tenho Um JFrame (AdicionarEscudo) que possui uma Tabela que exibe os nomes dos arquivos (logos em .png) de uma pasta, e ao clica-lá no nome do arquivo uma label recebe a imagem desse arquivo (como se fosse uma pré-visualização).

Funciona assim: Existe um JFrame com o nome AdicionarClube onde tem uma label que ao clicar abre então o JFrame AdicionarEscudo (citado anteriormente). Porém, não estou conseguindo setar a imagem selecionada no JFrame AdicionarEscudo para o frame anterior AdicionarClube.

OBS: Se eu aplicar AdicionarClube.set.Visible(true) ele abre a imagem selecionada em uma nova tela. Porém não quero que faça isso. Preciso que ele sete as informações na tela anterior e feche a tela AdicionarEscudos. Eu já instanciei e não consigo passar essa informação para o frame anterior.

Código;

TelaAdicionarClube tela_AdicionarClube = new TelaAdicionarClube();

JFRAME ADICIONARCLUBE (Ação funcionando normal ao clicar na JLabel para abrir uma nova tela e selecionar o seu escudo)

private void lbl_logoMouseClicked(java.awt.event.MouseEvent evt) {                                      
    TelaAdicionarEscudo tela_AdicionarEscudo = new TelaAdicionarEscudo();
    tela_AdicionarEscudo.setVisible(true);
} 

JFRAME ADICIONARESCUDO (Ação ao botão selecionar a imagem escolhida)

private void btn_SelecionarMouseClicked(java.awt.event.MouseEvent evt) {                                            
    this.dispose();
    String nome_arq = ""+tbl_Escudos.getValueAt(tbl_Escudos.getSelectedRow(), 0);
    ImageIcon escudo_logo = new ImageIcon("C:\\Users\\Rafa\\Documents\\NetBeansProjects\\ProjetoVomiliev\\escudos\\"+nome_arq);
    tela_AdicionarClube.lbl_logo.setIcon(new ImageIcon(escudo_logo.getImage().getScaledInstance(tela_AdicionarClube.lbl_logo.getWidth(), tela_AdicionarClube.lbl_logo.getHeight(), Image.SCALE_DEFAULT)));
    tela_AdicionarClube.setVisible(true);
} 

Alguém tem alguma dica?

Já ouviu falar em design patterns? E sobre o pattern observer?
Se não, é uma boa hora para estudar.
Se sim, vale lembrar que ele atende o que precisa.

Até então não conhecia, cheguei a estudar mas não consegui identificar o meu problema através disso.

Você não vai identificar mesmo, até porque esse pattern é a solução do teu problema.
Basicamente, você terá duas interfaces, a Observable e a Observer. Cada um dos JFrames que você criar, tanto o “base” quanto o “IncluirEscudo” (ou algo assim) vai implementar uma delas. A “base” implementa a interface Observer, que fica aguardando o “sinal” das classes que está observando, para executar algo.
Já a “IncluirEscudo” implementa a Observable, que vai avisar a todas as classes que a estão observando que algo ocorreu, como o upload de uma imagem que represente este escudo.
A partir daí, o problema está solucionado.

O Observer funciona nesse caso, mas acho que existe um outro padrão que é um pouquinho melhor, mais específico. A concepção do Observer foi focada em atender problemas de publish-subscribe, onde uma “estação” emite eventos constantemente, e os “ouvintes” se cadastram para receber esses eventos, e podem deixar de ouvir a qualquer momento. A informação enviada pela estação não é específica para nenhum de seus ouvintes, e cada ouvinte pode fazer o que quiser com aquela informação.

A ideia de utilizar o Observer nesse caso funciona, como citei anteriormente, onde a janela principal funciona como ouvinte, e a janela da foto seria a estação, como o colega @drsmachado citou. No Java, existem as classes Observer e Observable por padrão. Se a gente der uma olhadinha na documentação dessas classes, como no caso de Observer, vai ver a assinatura do método de notificação:

update(Observable o, Object arg)

O observable, no caso a janela da imagem, vai chamar update(this, imagem) ou algo assim, quando a imagem for escolhida pelo usuário.

Na janela principal, você vai implementar o método update. Você vai ter que fazer casts de Object para o teu tipo específico representando a imagem, seja um array de bytes, seja uma stream, qualquer coisa. Com isso, você tá deixando de utilizar o type check do compilador e pode cometer erros que não serão capturados na hora que compilar o código. Entende que você pode passar qualquer coisa ali no Object arg? Além do mais, se você está limitado a um argumento só. E se você quiser passar vários? Vai ter que criar uma classe nova só para envelopar os argumentos, adicionando mais getters no código final.

Por isso, eu acho (que fique bem claro, é só minha opinião) mais interessante utilizar um padrão de projeto como o Delegation, que funciona de uma forma bem similar, mas pode ser mais interessante por ter type checking, facilitando a captura de erros pelo compilador, como também a customização de parâmetros.

A ideia é bem parecida com a do Observer, mas tem um foco um pouco diferente. Funciona assim: Um objeto vai delegar a tomada de decisão a seu Delegate (aquele ao qual a tarefa é delegada).

Com isso, você pode implementar seu próprio esquema, mais ou menos assim.

Imagine que existem 3 classes no seu sistema: JanelaPrincipal, JanelaImagem e JanelaImagemDelegate.

public interface JanelaImagemDelegate {
    void usuarioEscolheuImagemEmJanelaImagem(JanelaImagem ji, {parâmetros que você quiser, em qualquer quantidade e tipo});
}

public class JanelaImagem extends JFrame (ou qualquer coisa de janela) {
    //...
    private JanelaImagemDelegate delegate;
    //construtor
    public JanelaImagem(JanelaImagemDelegate delegate) {
        this.delegate = delegate;
    }
    //...
    public void usuarioClicouNoBotaoDeSetarImagem() {
        // lógica para pegar a imagem escolhida
        delegate.usuarioEscolheuImagemEmJanelImagem(this, imagem, qualquer coisa);
    }
}

E finalmente

public class JanelaPrincipal extends JFrame (qualquer classe de janela), implements JanelaImagemDelegate{
    //...
    public void abreJanelaImagem() {
        JanelaImagem ji = new JanelaImagem(this);// parametro delegate passado, this
        // lógica para exibir a janela da imagem na tela
    }
    @Override
    public void usuarioEscolheuImagemEmJanelaImagem(JanelaImagem ji, parametros...) {
        // aqui você tem acesso aos parametros enviados pela JanelaImagem.
    }
    //...
}

Contra o meu argumento de especificidade do Delegate, você pode falar: Mas basta eu criar minhas próprias classes/interfaces Observer e Observable. Bem, com isso são duas, no Delegation só precisa de uma. Alem disso, se você utilizar isso em mais de um local além da parte da imagem, você vai ter que saber em cada implementação do update qual é o cast que deve ser feito, de Object para o que você quer. Com Delegation, você implementa um método específico para cada parte, que pode ser flexibilizado sem quebrar o código existente.

Entendi, obrigado pelas dicas @drsmachado @lvbarbosa!

Sendo bem sincero, eu desenvolvi em meu TCC um sistema de gestão hospitalar, usando swing.
Em algumas funcionalidades, como a pesquisa de medicamentos, eu implementei uma janela de pesquisa (um novo JFrame).Como eu não era apegado a design patterns, fiz da maneira que eu sabia: o JFrame de pesquisa recebia, no construtor, a instância do JFrame que o chamava. Desta forma e com métodos public, eu conseguia manipular o objeto referente à janela “principal” dentro da janela “filha”.
Não é o correto, mas funciona!

Você inventou teu próprio Delegation :stuck_out_tongue: hahahaha

@lvbarbosa, eu gambiarrei o que era possível. Implementei até coisas com threads, sem nunca ter visto thread na minha frente.
As tabelas eram todas no DefaultTableModel. E o mais bizarro de tudo foi que funcionou.

Imagino cara! É bem complicado a primeira vista, mas daí vai ficando mais simples depois que a gente quebra a cabeça um pouco.

Cara, eu não tenho ideia do que é o DefaultTableModel sem olhar na documentação. Até hoje eu não aprendi a mexer com Swing, hahahahah. Dei uma lida em como funciona a arquitetura (tipo a questão da thread de despacho de eventos), mas se você me pedir pra implementar algo, não vou saber inicialmente, teria que estudar mais a fundo. Respondo as perguntas do pessoal aqui no forum sobre Swing só lendo a documentação. Geralmente, como é o caso dessa aqui, não é especificamente sobre Swing, mas sim sobre arquitetura e design de classes.