Refatoração: Remover atribuições a parâmetros e Encapsulamento

Estou com um problema que eu acho que esta relacionado com esta refatoração! Gostaria da opinião de vocês!

O problema é o seguinte:

No sistema que estou trabalhando temos uma arvore onde valores são relacionados a endereços. Criei um fachada para facilitar a manipulação da arvore, ou seja, fazer com que o cliente da fachada não precise saber manipular nós da arvore, só precise saber utilizar endereços e valores.

Esta arvore tem que ser exibida na minha visão (JTree). Para isso criei um adaptador da fachada de arvore para TreeModel. Levando em conta que so os endereços devem ser exibidos, meu adaptador só recupera endereços e os envia para a JTree. A JTree utiliza esses endereços para fazer consultas através do meu adaptador para verificar qtos filhos o endereço tem, se é folha ou não, coisas desse tipo.

Meus nós da árvore matém seus endereços encapsulados, retornando cópias do seu endereço quando alguém deseja saber seu endereço. Desta maneira podemos ver que a JTree possui cópias dos endereços existentes na árvore. Com este encapsulamento o endereço de nó só pode ser alterado através da interface exposta por nó.

Meu problema realmente começa aqui:

A JTree por sua vez, a meu ver, não possui um encapsulamento tão bom, pois quando ela faz um pedido ao meu adaptador para TreeModel ela passa seus próprios dados invés de cópias. Com isso quando eu manipulo o parâmetro endereço para verificar se ele é uma folha na arvore consequentemente eu altero minha JTree. Que M ai FD tudo!

Penso que tenho dois problemas:

1- A JTree tinha que manter seu encapsulamento e tratar seus dados não ficar expondo-os a todos! Já que ela não o faz eu derrepente vou ter que faze-lo;

2- Meu mecanismo de arvore não deveria alterar os parâmetros qeu são passados para ele. Além do mais eu acho que não é de responsabilidade dos métodos de consulta alterar os parametros que são passados como referencia para ele. Sua responsabilidade é só fazer uma consulta.

Soluções que eu penso:

Solução para o problema 1: Fazer com que todos objs que JTree tenha contato mantenha o encapsulamento para ela! TreeModels, CellRenders etc…

Solução para o problema 2: Fazer com que o mecanismo de arvore crie cópias dos parametros que ele precisa manipular para não fugir da sua responsabilidade e acabr alterarndo os parametros.

Para ficar legal eu acho que tenho que aplicar as 2 solução só que com isso tenho que ficar criando cópia de uma lado para outro, tanto quando vou chamar um método quanto vou manipular um parâmetro. Será que isso é legal? Vai ser dificil ficar lembrando de criar cópias, fora o desempenho que vou perder…

Se eu fugir disso e aplicar uma unica solução da conta do recado, mas em contra mão eu posso ficar com o encapsulamento ruim ou com a responsabilidade ruim em alguns metodos.

Esse problema me lembrou a refatoração do Fowler e fui lá conferir…

Aguardo a ajuda de vcs []s

Uma das boas dicas do livro Effective Java, do Joshua Bloch, é efetivamente:
“Faça cópias de segurança” (veja o item 24 do capítulo 6 do livro).

http://java.sun.com/docs/books/effective/chapters.html

Se você realmente quer garantir que objetos internos não violem sua JTree, ou você torna os objetos que os nós da JTree tem imutáveis, ou faz cópias de segurança.

Beleza manter o encapsulamento fazendo até como eu disse aqui: (Mas anida sim posso perder por ficar criando várias cópias)

Ontem tava realmente pensando em colocar minha classe Endereco para ser um obj valor (Imutável). Essa me parece uma boa solução, vou pensar mais ao respeito…

Mas e com relação ao pensamento que tive sobre encapsulamento e a responsabilidade do método. Será que segui uma linha de reciocinio correta?