Fragmental

A partir do momento que você resolve utilizar uma tecnologia deve fazer o possível para entendê-la. Hoje eu estava conversando com um amigo e percebi que por mais que estejam espalhados os conceitos ainda não são entendidos. Falávamos sobre JPA e sobre como misturar lógica de negócios com metadados de persistência pode se tornar um problema em longo prazo. O argumento em favor da mistura foi “mas sua lógica de negócios não precisa ficar anotada, apenas seus dados”. Aí eu percebi que a discussão, na verdade, precisava passar por algo mais fundamental.

Eu expliquei o problema de usar VOs e BOs (que ele não chamava por estes nomes mas aplicava os conceitos) através de um exemplo simples.

Vamos supôr que exista uma função que define o novo salário de um funcionário (pseudo-codigo):

public void aumentaSalario(Funcionario f, Valor v){
Valor salario = v + calculaTaxasCargo(f.getCargo());
f.setSalario(salario);
}

E vamos supor que exista um tipo de funcionário chamado Gerente. O Gerente possui uma lógica de cálculo de salário um pouco diferente, dada pela formula:

salario = v + calculaTaxasCargo(f.getCargo()) + (f.getDepartamento().getOrcamento().getBonus() / 10)


Como adaptamos o código acima para que isso seja possível? Uma forma é criar um novo método:

public void aumentaSalario(Funcionario f, Valor v){
Valor salario = v + calculaTaxasCargo(f.getCargo());
f.setSalario(salario);
}
public void aumentaSalarioGerente(Gerente f, Valor v){
Valor salario = calculaSalario(f,v) + (f.getDepartamento().getOrcamento().getBonus() / 10);
f.setSalario(salario);
}

Mas desta forma nós sempre precisamos saber se estamos lidando com um gerente ou funcionário para saber qual função chamar. Se temos uma lista como a abaixo (que pode ser retornada do banco de dados, por exemplo) precisamos verificar cada tipo:

List<Funcionario> lista = new ArrayList<Funcionario>();
.
lista.add(new Gerente("João"));
lista.add(new Funcionario("Lucia"));
.
//aumentando o salario de todo mundo em 1000 dinheiros
for(Funcionario f: lista){
if(f instanceof Gerente){
aumentaSalarioGerente(f,1000);
}
else{
aumentaSalario(f,1000);
}
}

De que adianta ter uma abstração na forma de herança entre Funcionario e Gerente se cada vez que eu preciso manipulá-las eu preciso quebrar esta abstração com um if? Ok, é fácil de resolver isso criando uma função única:

public void aumentaSalario(Funcionario f, Valor v){
Valor salario = v + calculaTaxasCargo(f.getCargo());
.
if(f instanceof Gerente){
salario = calculaSalario(f,v) + (f.getDepartamento().getOrcamento().getBonus() / 10);
}
f.setSalario(salario);
}
.
//Aumentando salarios:
List>Funcionario> lista = new ArrayList>Funcionario>);
.
lista.add(new Gerente("João"));
lista.add(new Funcionario("Lucia"));
.
//aumentando o salario de todo mundo em 1000 dinheiros
for(Funcionario f: lista){
aumentaSalario(f,1000);
}

Mas o que eu fiz foi simplesmente mudar o problema de lugar, não acabar com ele (por isso minha métrica do if).

E qual a solução? Polimorfismo.

class Funcionario{
.
public void aumentaSalario(Valor v){
Valor salario = v + calculaTaxasCargo(this.getCargo());
this.salario = salario;
}
.
}
.
class Gerente extends Funcionario{
.
public void aumentaSalario(Valor v){
super.aumentaSalario(v);
//soma o bonus de gerente ao salario
f.setSalario(salario);
this.salario = this.salario+ (getDepartamento().getOrcamento().getBonus() / 10);
}
.
}

Daí nossa lista de aumento em massa pode fazer simplesmente:

//Aumentando salarios:
List>Funcionario> lista = new ArrayList>Funcionario>();
.
lista.add(new Gerente("João"));
lista.add(new Funcionario("Lucia"));
.
//aumentando o salario de todo mundo em 1000 dinheiros
for(Funcionario f: lista){
f.aumentaSalario(1000);
}

Porque cada objeto tem em si a lógica necessária para realizar a operação. Claro que este é um exemplo acadêmico, já identifiquei uma penca de refactorings necessários para o código ficar aceitável, mas a idéia está expressa nessa simples divisão de responsabilidade.

Aí é hora de alguém postar um comentário dizendo: “mas estes objetos ‘gordos’ têm toda a lógica? Fazem persistência?” a resposta é não. Objetos são ‘animais sociais e colaborativos’, o que significa que eles agem em conjunto com outros objetos para chegar a um fim. No exemplo acima, o cálculo sobre quanto é o bônus não é feito pelo funcionário, nem pelo gerente mas sim sobre quem é “dono” do conceito (dica: esta parte pode ser refatorada se você ler sobre o Princípio de Deméter).

Objetos dividem as responsabilidades e agem em conjunto para executar as regras de negócio de um sistema. Parece simples mas cada vez mais eu acho que as pessoas não gostam de conceitos simples :(

This entry was posted on Thursday, March 29th, 2007 at 1:49 pm and is filed under java, orientacao.a.objetos, programando. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.