Como fazer este codigo orientado a objeto

Tente fazer uso do polimorfismo. Este link pode ser de grande ajuda para você:

http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html

No Java, há uma maneira bastante interessante de eliminar ifs usando enum. Dá uma olhada nesse tópico:
http://www.guj.com.br/posts/list/55885.java

Vc tem várias formas de resolver. OO é como fazer bolos, o mesmo bolo pode ser feito de formas diferentes por diferentes cozinheiros (claro que o sabor será diferente … 8) )

Vc identificou classes de peso por um numero. Vc poderia usar esse numero para obter a taxa. É bem linear
Mas tlv vc queria fazer algo mais generico. Dado o ano do carro e o peso calcular a taxa.

Bom, vc vai precisar de um calculador de taxas que muda sua logica conforme o ano e a taxa
O uso seria mais ou menos assim:

CalculadorTaxa cal = CalculadorTaxa.getInstance(1990); //1990 é o ano
double taxa = cal.getTaxa(1230); // 1230 é o peso

Não se trata de criar um singleton e sim um abstract factory. A classe CalculadorTaxa tem logica dinamica , ou seja, a logica muda no tempo ( conforme mudam as leis ,etc…)

class abstract CalculadorTaxa {

public static CalculadorTaxa  getInstance(int ano, double peso){

   if (ano&lt=1970){
         return CalculadorTaxa1970();  
   } else if (ano &lt 1980){
         return CalculadorTaxa1971();  
   } else {
         return CalculadorTaxa1980();  
   }

}


public abstract double getTaxa(double peso);

protected class CalculadorTaxa1971{

public double getTaxa(double peso){

if (peso &lt 1200){
    return 27;
} else if (peso &lt 1700){
    return 30.50;
} else {
    return 52.50
}
}

}

// .. o mesmo para as outras classes
}

Bom, vendo bem os ifs não desapareceram…
Suponho que poderiamos usar um mecanismo de matrizes, mas esse não é o ponto.
Alguem consegue fazer com menos ifs ?

Você pode fazer a classe CalculadorTaxa saber em que anos ela trabalha. Depois, basta cadastrar objetos dessa classe numa lista e perguntar para eles, ao invés de fazer com ifs.

public CalculadorTaxa getCalculadorParaOAno(int ano) { for (CalculadorTaxa calculador : calculares) { if (calculador.workForYear(ano)) return calculador; return null; //Nenhum calculador para aquele ano }

Os ifs do peso são mais difíceis de eliminar, pois são muito específicos do calculador de taxas. Eu imagino que poderia usar a mesma estratégia, mas acho que os benefícios não seriam tão grandes assim.

Fazer um enum de calculadores de taxa, como mostrei no artigo ali em cima, também pode ser uma boa. Aí aquele método ali em cima poderai ser estático, obtendo o objeto do enum adequado de acordo com o ano.

ViniGodoy:

Você pode fazer a classe CalculadorTaxa saber em que anos ela trabalha. Depois, basta cadastrar objetos dessa classe numa lista e perguntar para eles, ao invés de fazer com ifs.

public CalculadorTaxa getCalculadorParaOAno(int ano) { for (CalculadorTaxa calculador : calculares) { if (calculador.workForYear(ano)) return calculador; return null; //Nenhum calculador para aquele ano }

É uma boa, eu tinha pensando em usar map, mas não estava vendo que chave usar.
E como estipular para os calculadores finais? Por exemplo, o calculador de 71 a 79 era válido em 77
e o codigo de workForYear() deveria seria : return ano &gt 1970;
Mas em 80 aparece outro e o codigo tem que ser mudado para return ano &gt 1970 && ano &lt 1980
Isso provoca a edição de um calculador em vez da edição da fábrica. Será que isto compensa a retirada dos ifs ?

Fazer um enum de calculadores de taxa, como mostrei no artigo ali em cima, também pode ser uma boa. Aí aquele método ali em cima poderai ser estático, obtendo o objeto do enum adequado de acordo com o ano.

Mas isso é a mesma coisa. Vc teria que usar um getCalculadorParaOAno(ano) do mesmo jeito para descobrir qual enum seria o bom. O Enum só seria melhor se fosse ser usado explicitamente todas as vezes, o que provavelmente não é o caso já que a informação está num outro objeto (Carro, p.ex.).

Acho que compensa. Quando você editar um novo calculador, supondo que todos os calculadores tenham uma interface em comum, vai ter que se preocupar com o método workForYear. Fica bastante explícito. Se você manter um if, vai ter que se lembrar que esse if está em algum lugar (e torcer para que esteja em só um lugar). Me parece lógico que essa regra de negócio, já que está diretamente relacionada a funcionalidade de um calculador, esteja implementada no próprio calculador em si.

Você também pode obter calculadores dinamicamente, seja por algum mecanismo de injeção de dependência, por um cadastro externo ou por um registro qualquer.

E, por fim, esse método também pode acabar se tornando útil em outros trechos do código.

É realmente a mesma coisa. O enum é interessante pq a lista de values() já é implementada em built-in. Mas, como você mesmo falou, só é legal quando o conjunto de valores é relativamente fixo e pode ser usado diretamente, como no caso do enum que dei no exemplo (onde um SearchCriteria vai ser usado diretamente em vários trechos do código).

Valeu Vini e Sergio,

To tao ocupado que so tive tempo de implementar agora.
Implementei usando polimorifsmo Nao consegui eliminar os ifs, mas a ideia me ajudou a deixar o codigo mais reutilizavel.

Com os enums nao consegui implementar nessa situação. Mas fiz em uma outra situação onde os valores eram fixos, e ficou bem legal a solução.