Atributos da classe em HASHMAP (Redução de código)

Atributos de classes em Map? Mas pq?

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).

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 mais respostas! []'s. :roll:

Vc pode continuar declarando as componentes gráficos na classe e então adicione eles tb no Map.
Dai vai aparecer no diagrama de classes!

fabiofalci:

Vc pode continuar declarando as componentes gráficos na classe e então adicione eles tb no Map.
Dai vai aparecer no diagrama de classes!

Sim, concordo. A linha de raciocínio que você seguiu para responder está correto.

Mas o Diagrama de Classes vai mostrar somente os atributos. Não estarão presentes os métodos modificadores deles. Na classe estará um atributo do tipo HASHMAP, esse sim com métodos GETS/SETS universais. Para quem olha o DC (Diagrama de Classes), vai logo entender que esses atributos especificados são para uso próprio da classe (Atributos privados, sem métodos modificadores, seguindo fielmente o encapsulamento). E continuaremos sem saber quem são as key’s (chaves) do HASHMAP para busca e acesso no seu respectivo GET/SET universal. :sad:

Caímos no problema inicial de integração da equipe que desenvolve a visão da equipe que desenvolve o controle. Será que existe um documento auxiliar para o DC na qual especifico os nomes da key’s do HASHMAP? :idea:

Não deixe de opinar!

Olha para ajudar a entender melhor o problema:

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.

Já no segundo caso, a integração é praticamente 0% :sad: 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…

Aguardo respostas, sugestões, críticas, não tenha vergonha! O que vale é a opinião. Abração a todos.

Ninguém mesmo? Nem uma opinião?

Cara eu estava utilizando essa técnica de encapsulamento de propriedades, e eu pensei nesse problema, resolvi criando uma classe de constantes para cada map que eu criava, exemplo: se eu tenho uma classe Usuario e esse usuário tem um map userAttributes, eu criava uma classe UserAttributeMapKeys que conteria todas as chaves como constantes nessa classe. Pode não ser a melhor solução mas é uma.