Olá, estou com uma nova dúvida, agora na modelagem: Na verdade, os nomes dos atributos do tipo JTextField de uma classe de cadastro se tornaram chaves (key) do HashMap<String, JTextField>. Em um diagrama de classes, por exemplo, como faço para detalhar os atributos, já que se tornaram chaves de HashMap e são criados por ele?
Ex:
Map<String,JTextField> cadastro = new HashMap<String,JTextField>();
cadastro.add("RG", new JTextField());
cadastro.add("CPF", new JTextField());
cadastro.add("Telefone", new JTextField());
Para ser mais radical na pergunta, imagine que estou usando uma Arquitetura como MVC, onde quem faz a visão não conhece nada sobre o controle. Porém, o controle deverá conhecer os componentes da visão quando precisar alterar algo no modelo (recolhendo dados das caixas de texto da visão e dando Set’s no modelo). Usando HashMap, o desenvolvedor do controlador não saberá quais são os atributos da classe na visão, pois não foram explicitamente instanciados como atributos da classe.
Como vou modelar isso em um Diagrama de classes?
Ninguém arrisca mesmo? Nem um palpite?
Vou tentar expor mais o problema: 
Na verdade, o correto são os atributos serem explicitamente declarados na classe. Hoje, o controle conhece os métodos GET/SET da visão que retornam e enviam String’s. Esses métodos e atributos são mostrados no diagrama de classes da visão.
Mas na verdade eu queria fazer um HASHMAP para substituir os atributos da classe visão. Ou seja, o nome dos atributos dos JTextField virariam chaves do HASHMAP e o conteúdo os próprios JTextFields. Então o controle acessaria sempre o HASHMAP com um método GET/SET universal para JTextFields simplesmente passando a chave (key) e inserindo/retornando o conteúdo do mesmo.
A técnica é boa para manutenção e redução de código. Porém, se você pegar o diagrama de classes da visão com o HASHMAP no lugar dos atributos, jamais a pessoa que faz o controle (olhando somente o diagrama de classes da visão) vai saber quem são as keys desse HASHMAP que está na visão.
Espero por respostas! 
Obrigado a todos que estão tentando colaborar!
Acho que o diagrama de classes e a implementação não precisariam ser rigidamente amarrados (embora isso fosse desejável se você usasse algum recurso de geração de código). Eu deixaria o diagrama de classes como está.
De qualquer maneira, por reflection você pode pegar um campo pelo nome, o que não é tão bonitinho quanto o hashmap mas acho um pouco mais fácil de manter em alguns aspectos.
[quote=thingol]Acho que o diagrama de classes e a implementação não precisariam ser rigidamente amarrados (embora isso fosse desejável se você usasse algum recurso de geração de código). Eu deixaria o diagrama de classes como está.
De qualquer maneira, por reflection você pode pegar um campo pelo nome, o que não é tão bonitinho quanto o hashmap mas acho um pouco mais fácil de manter em alguns aspectos.[/quote]
Olá thingol 
Então realmente havia visto um artigo aqui do GUJ mesmo sobre reflection chamado “Java e Reflection”.
Mas analisando bem e aplicando o código acaba ficando maior do que com hashmap.
Vamos imaginar um cadastro qualquer, lá nele alguns JLabel’s e JTextField’s. (isso na visão)
Veja o código:
import javax.swing.*;
class Cadastro {
private tfNome;
private tfSobrenome;
private tfRG;
// ... Muitos atributos do cadastro.
Cadastro() {
JPanel painel = new JPanel();
painel.add(new JLabel("Nome:"));
tfNome = new JTextField();
painel.add(tfNome);
painel.add(new JLabel("Sobreome:"));
tfSobrenome = new JTextField();
painel.add(tfSobrenome);
painel.add(new JLabel("R.G:"));
tfRG = new JTextField();
painel.add(tfRG);
// ... Repetindo para todos os atributos.
}
// ... Gets/Sets para todos os atributos.
}Agora se eu usar o HashMap, veja só:
import javax.swing.*;
class Cadastro {
private Map<String,JTextField> cadastro = new HashMap<String,JTextField>();
Cadastro() {
JPanel painel = new JPanel();
painel.add(new JLabel("Nome:"));
painel.add(cadastro.put("tfNome", new JTextField())); // "put" retorna o objeto inserido na chave.
painel.add(new JLabel("Sobrenome:"));
painel.add(cadastro.put("tfSobrenome", new JTextField()));
painel.add(new JLabel("RG:"));
painel.add(cadastro.put("tfRG", new JTextField()));
// ... Repetindo para todos os atributos. Poderia até fazer um "for" para ler um vetor com as chaves (que tem os nomes dos atributos).
}
// ... Gets/Sets UNIVERSAIS para todos os atributos. Passa a key para o get e no set passa a key e o valor. Ou seja, dois métodos para todos os atributos.
}Veja a redução de código (7 linhas) e a facilidade de manutenção com HASHMAP é incrivelmente superior ao do primeiro caso. Eu posso adicionar/remover (em duas únicas linhas) um JTextField sem a preocupação de ver mais nada, principalmente nos métodos gets/sets. Concorda comigo?
O problema todo é: Como vou documentar isso para o pessoal que desenvolve o controle? :?:
No primeiro caso, a integração do “pessoal que cuida da visão” com o “pessoal que cuida do controle” é praticamente 100%. O pessoal do controle só de bater o olho no Diagrama de Classes do pessoal da visão já identifica os métodos necessários para recolher os dados da visão. Fácil de integrar. 8)
Já no segundo caso, a integração é praticamente 0% :lol: Visto que se o “pessoal do controle” olhar o Diagrama de Classes do “pessoal da visão” vai ter a surpresa de ver um atributo do tipo HashMap e vai lá saber quais são os nomes das keys (chaves) inseridas nele para identificar Nome, Sobrenome, Rg, etc… :shock:
Aguardo respostas, sugestões, críticas, não tenha vergonha! O que vale é a opinião. Abração a todos.
Esse 0% de integração que é a derrocada de usar HashMaps.
Visão e controle não foram feitos para ficarem isolados; ambos pertencem ao mesmo lado da aplicação e trabalham em sincronia. O model é que fica isolado, sem saber da existência dos outros dois.
Colocando uma HashMap no meio você retira todo o poder de autocompletar das IDEs, acaba mais atrapalhando o desenvolvimento que ajudando. Eu imagino que algumas otimizações da JVM fiquem de fora por não conseguir fazer uma ligação direta entre as classes.
[quote=Bruno Laturner]Esse 0% de integração que é a derrocada de usar HashMaps.
Visão e controle não foram feitos para ficarem isolados; ambos pertencem ao mesmo lado da aplicação e trabalham em sincronia. O model é que fica isolado, sem saber da existência dos outros dois.
Colocando uma HashMap no meio você retira todo o poder de autocompletar das IDEs, acaba mais atrapalhando o desenvolvimento que ajudando. Eu imagino que algumas otimizações da JVM fiquem de fora por não conseguir fazer uma ligação direta entre as classes.[/quote]
Olá Bruno,
Concordo plenamente com o que escreveu sobre o isolamento e o uso de IDE’s.
Mas, repare bem em ambos os códigos acima que coloquei como exemplos para mostrar diferenças… e imagine que o desenvolvedor descarta o uso de IDE’s.
A redução de código e a manutenção do segundo exemplo é simples, muito simples. Porém quem vai garantir (dar a certeza) que determinadas chaves do HashMap vão estar lá presentes quando, por exemplo, o controle solicitar um dado (conteúdo do JTextField)? Até porque quem desenvolve as partes gráficas (visão) é uma equipe e quem desenvolve o coração da aplicação (controlador) é outra equipe. Na verdade eu estaria precisando complementar a documentação existente adicionando uma especificação de chaves para o HashMap da classe. Porém sabemos que essa documentação auxiliar não é um padrão e poderá acabar gerando confusão. Aí pergunto: Existe algo para documentar esse tipo de situação? Ou até mesmo uma outra solução que fique igual ou até melhor que a do segundo exemplo e que seja compreendida por todos?
Agradeço a todos que estão colaborando! Abraço.