Como no aprender Java e Orientao a Objetos: getters e setters

Postado em 14. set, 2006 por Paulo Silveira em Arquitetura, Java Compartilhar Muitas pessoas perguntam como aprender OO?. H vrias maneiras de aprender OO, creio que no tenha uma melhor, mas existem maneiras de no aprender.

Uma das prticas mais controversas que aprendemos no incio a gerao indiscriminada de getters e setters. Os exemplos bsicos de centenas de tutoriais java esto recheados com getters e setters da pior espcie: aqueles que no fazem sentido algum. Considere:
class Conta { double limite; double saldo; }

Rapidamente os tutoriais explicam o private para o encapsulamento. Mas a como acessar? Getters e setters nela!
class Conta { private double limite; private double saldo; public double getSaldo() { return saldo; } public void setSaldo(double saldo) { this.saldo = saldo; } public double getLimite() { return limite; } public void setLimite(double limite) { this.limite = limite; } }

Qual o sentido desse cdigo? Para que esse setSaldo? e esse setLimite? e o getLimite? Voc vai usar esse mtodos? Nunca crie um getter ou setter sem sentir uma real necessidade por ele. Isso uma regra para qualquer mtodo, mas particularmente os getters e setters so campees: muitos deles nunca sero invocados, e grande parte do restante poderia ser substitudo por mtodos de negcios. Cdigos do tipo conta.setSaldo(conta.getSaldo() + 100) se espalharo por todo seu cdigo. Segue ento a nossa classe Conta reformulada de acordo com essa necessidade:
class Conta { private double saldo; private double limite; public Conta(double limite) { this.limite = limite; } public void deposita (double x) { this.saldo += x; } public void saca(double x) { if(this.saldo + this.limite >= x) { this.saldo -= x; } throw new IllegalArgumentException("estourou limite!"); } public double getSaldo() { return this.saldo; } }

E nem estamos falando de test driven development! Testando a classe Conta rapidamente voc perceberia que alguns dos getters e setters anteriores no tm uso algum, e logo sentiria falta de alguns mtodos mais voltados a lgica de negcio da sua aplicao, como o saca e o deposita acima. Esse exemplo muito trivial, mas voc pode encontrar por a muitas classes que no tem a cara de um java bean que expem atributos como Connection, Thread , etc, sem necessidade alguma! Existem sem dvida prticas piores: utilizao de ids para relacionar os objetos, arrays no encapsuladas como estruturas, cdigo fortemente baseado em comparao de Strings hardcoded (que o Guilherme Silveira sarcasticamente carinhosamente batizou de POS, ou programao orientada a strings), milhares de mtodos estticos, entre outros. Todas essas prticas so muito comuns quando estamos comeando a quebrar o paradigma procedural, e confesso j ter sido um grande praticante de muitas delas. Um professor sempre me disse que voc s vai utilizar bem o paradigma da orientao a objetos depois de errar muito. O Phillip Calado tem um artigo simplesmente incrvel que de certa forma aborda esse tema: classes fantoches (puppets). Uma classe fantoche a que no possui responsabilidade alguma, a no ser carregar um punhado de atributos! Onde est a orientao a objetos? Uma grande quantidade de classes fantoches so geradas quando fazemos Value Objects, entidades do hibernate, entre outros.

Mas o que colocar nas minhas entidades do hibernate e nos meus VOs alm de getters e setters?. Antes de tudo, verifique se voc realmente precisa desses getters e setters. Para que um setID na sua chave primria se o seu framework vai utilizar reflection ou manipulao de bytecode para pegar o atributo privado, ou se voc pode pass-la pelo construtor? Sobre value objects, voc realmente precisa dos seus setters? Em muitos casos VOs so criados apenas para expor os dados, e no h necessidade alguma para os setters bastando um bom construtor! No hibernate costumo colocar alguns mtodos de negcio, algo parecido como na classe Conta. Minhas entidades possuem uma certa responsabilidade, em especial as que dizem respeito aos atributos pertencentes a elas. Para quem ainda est aprendendo, a apostila da caelum de java e orientao a objetos tem algumas dessas discusses e procura ensinar OO comentando sempre dessas ms prticas, como por exemplo o uso de herana sem necessidade.