Objetopolis

15:28 in bla bla bla

Bem Vindo a Objetopolis.

Assim começa o segundo capitulo do livro Java! Use a Cabeça (Se não for também não interessa :P), copiei esse termo do livro, simplemente para ressaltar o que quero dizer.

Existem alguns que dizem que controlar o fluxo da informaçã com IFs é uma quebra ao paradigma orientado a objeto, porém nem todos os casos existe a necessidade de criar uma Interface e/ou ENUM para contornar IFs, salvo em alguns casos. Muitas vezes o excesso de abstrações para forçar/evitar o uso de algumas estruturas de controle ditas não-oo podem tornar o código menos legivel. Eu acredito que a beleza do codigo é grande parte da beleza de um sistema, concerteza um sistema bem escrito será um sistema que conterá a integração continua, e nenhum desenvolvedor que chegar até o sistema vai abandona-lo.

O que eu defendo quando se escreve um software é, pense em como vc vai ler isso aqui daqui a alguns meses, normalmente 1 mês basta para termos vontade de excluir todos os nossos codigos e reafaze-los aplicando novas tecnicas e funções, isso não é regra, mas como qualquer desenvolvedor que se preze está sempre em constante evolução seu novo conhecimento pode melhorar ou ajudar a escrever o codigo de forma mais elegante.

Apesar de tudo que eu disse sobre os IFs, eu não gosto de usa-los, acredito que deixa o código "tosco", existem situações em que ele é necessário. Muitos ifs podem ser evitados como por exemplo:

view plainprint?

1. if( c == 0){  
2.   
3.    return true;  
4.   
5. }else{  
6.   
7.    return false;  
8.   
9. }  

if( c == 0){

   return true;

}else{

   return false;

}

esse código é facimelmente convertido em uma linha:

view plainprint?

1. return c == 0;  

return c == 0;

Em alguns casos o operador ternário tbm pode ser muito bem empregado, aumentado a legibilidade do código, lembre-se um sistema não é mais definido por linhas de código :D

Algo que eu gosto muito de fazer e usar um pouco de reflection, atrelado a um HasMap, com simples linhas de código temos um código mais legivel, como por exemplo, no item abaixo, abre-se uma determinada tela de um sistema utilizando esse recuro.

view plainprint?

1. class Controller implements ActionListener{  
2.   
3.    private Map<jbutton, class<?="">> botoes = new HashMap<jbutton, class<?="">>();  
4.   
5.   
6.   
7.    public void actionPerformed(ActionEvent e){  
8.   
9.           Class tela = botoes.get((JButton) e.getSource());  
10.   
11.           if(tela != null){  
12.   
13.                 criaTela(tela);//Cria a tela para ser mostrada  
14.   
15.           }else{  
16.   
17.                raiseErro("Tela não encontrada!"); //monstra erro na tela  
18.   
19.           }  
20.   
21.    }  
22.   
23.     public void registraBotao(JButton botao, Class<!----> tela){  
24.   
25.           botoes.put(botao, tela);  
26.   
27.     }  
28.   
29. }  
30.   
31. </jbutton,></jbutton,>  

class Controller implements ActionListener{

   private Map> botoes = new HashMap>();



   public void actionPerformed(ActionEvent e){

          Class tela = botoes.get((JButton) e.getSource());

          if(tela != null){

                criaTela(tela);//Cria a tela para ser mostrada

          }else{

               raiseErro("Tela não encontrada!"); //monstra erro na tela

          }

   }

    public void registraBotao(JButton botao, Class tela){

          botoes.put(botao, tela);

    }

}

voila, temos um código limpo e facil de ser explicado, não existe problema em ler esse codigo, ele é completamente intuitivo, um único if, e um pouco de dinamismo, e lhes apresento um Controller desvinculado a uma tela. e se adiconar um botão não existe necessidade de criar um novo actionListener para abrir uma tela.

PS: esses exemplos foram criados a mão, aqui no blog, as chances disso não compilar são grandes, é meramente ilustrativo

Por isso que ressalto, muitas vezes para usarmos objetos, sempre que existe uma necessidade, cada objeto deve ter suas funções bem definidas, como li um dia o Sergio Taborda disse, se um objeto é somente para ser um apunhado de atributos com getters e setters que seja, desde que ele tenha sua funcionalidade bem definida.

Viajei nesse post, começei criticando algo que eu faço pra defenter o uso de objetos sempre hehhe.

Só mais um detalhe
Esqueçam os tipos primitivos, utilizem os wrappers A perca de performance é minima, e vc trabalha em um nivel superior aos tipos primitivos.

isso aí povo até mais.