Java Effective

Programação – Item 55

Postado em Updated on

Online_video_marketing_optimize_conversion_rates_tips_id35618561Otimize Criteriosamente

A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de gerador de perfil e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.

Para todas as informações, veja o post inicial.

“Tudo quanto, pois, quereis que os homens vos façam, assim fazei-o vós também a eles; porque esta é a Lei e os Profetas.” Mateus 7:12

Programação – Item 54

Postado em

downloadUse métodos nativos criteriosamente

O uso de métodos nativos apresentam desvantagens perigosas:

  1. Não são seguros por estarem abertos a erros de adulteração de memória.
  2. Dependência de plataforma especifica.
  3. Custo de desempenho pelo acesso e abandono associado ao código nativo.
  4. Difícil e tedioso de escrever e ler.
  5. São difíceis de depurar.

Diante destes fatos pense duas vezes antes de usar métodos nativos. Sempre tente utilizar a menor quantidade possível.

Para todas as informações, veja o post inicial.

“Não acumulem para vocês tesouros na terra, onde a traça e a ferrugem destroem, e onde os ladrões arrombam e furtam. Mas acumulem para vocês tesouros nos céus, onde a traça e a ferrugem não destroem, e onde os ladrões não arrombam nem furtam.” Mateus 6:19-20

Programação – Item 53

Postado em

zooms-2195-0Prefira interfaces à reflexão

Reflexão é um recurso muito poderoso necessário para execução de certas tarefas sofisticadas de programação, usada na implementação de recursos bem específicos. É acompanho de muitas desvantagens:

  1. Perda dos benefícios da verificação de tempo de compilação.
  2. A codificação ficara deselegante, complexo e verboso.
  3. Perda no desempenho.

Diante disso, sempre prefira usar estruturas baseadas no contrato de interfaces polimórficas (Item 52) do que reflexão pura. Veja que na verdade, isso resulta em uma forma limitada de reflexão com seus benefícios, sem incorrer em tantas desvantagens. Somente use reflexão em casos realmente necessários que demandem estruturas altamente dinâmicas e genéricas.

Para todas as informações, veja o post inicial.

“Pelo que também Deus o exaltou soberanamente e lhe deu um nome que é sobre todo o nome…” Filipenses 2:9

Programação – Item 52

Postado em

cerealReferencie objetos por sua interface

Para obter o máximo de flexibilidade de manutenção de código, sempre prefira referenciar objetos através de uma interface apropriada ou classe abstrata. Aplique isso para todos os elementos de programação: parâmetros, propriedades e tipos de retorno. Seguem os únicos lugares aceitáveis para se referenciar classes concretas:

  1. Para criação de objetos polimórficos dentro de construtores.
  2. Quando um objeto não possuir interface ou classe abstrata.
  3. Quando usar objetos imutáveis que represente valores sem identidade (item 15) como o caso dos wrappers.

Para todas as informações, veja o post inicial.

“Antes, crescei na graça e no conhecimento de nosso Senhor e Salvador Jesus Cristo. A ele seja a glória, tanto agora como no dia eterno.” 2 Pedro 3:18

Programação – Item 51

Postado em

Caution_Cuidado_BTPY03K1Cuidado com o desempenho na concatenação de strings

Cada operação de concatenação de strings com o operador “+” gera um novo objeto string com seus respectivos conteúdos copiados. Isso acontece pelo simples fato da classe string ser imutável (item 15). Diante disso, não use o operador de concatenação para combinar mais do que algumas strings, evitando essa exponencial perca de tempo de desempenho quântico. Para gerenciar volumes grandes de strings, use a classe StringBuilder e seus respectivos métodos.

Para todas as informações, veja o post inicial.

“Porque, se vivemos, para o Senhor vivemos; se morremos, para o Senhor morremos. Quer, pois, vivamos ou morramos, somos do Senhor.” Romanos 14:8

Programação – Item 50

Postado em Updated on

avoidEvite usar String onde outros tipos forem mais apropriados

Devido ao suporte automático e a sua facilidade de sintaxe, existe uma tendência natural ao uso extrapolado do tipo String para fins diferentes daqueles para os quais foram projetadas. Somente use String para representar dados que realmente tenha natureza única e exclusivamente textual. Sendo assim, não use string para representar valores inteiros, monetários, datas, booleanos, enumerados ou tipos específicos de negócio como CPF, CNPJ etc. Valores representados erroneamente com String são confusos, menos flexíveis, lentos, propensos a erros e não precisam ser convertidos para seu tipo correspondente quando necessitarem de operações especifica.

Para todas as informações, veja o post inicial.

“Portanto, vede prudentemente como andais, não como néscios, e sim como sábios, remindo o tempo, porque os dias são maus.” Efésios 5:15-16

Programação – Item 49

Postado em Updated on

mqdefaultPrefira usar tipos primitivos ao invés de wrappers

Na versão do Java 1.5, os recursos de autobox/unbox ofuscaram, mas não eliminaram a distinção entre tipos primitivos e os seus correspondentes wrapper.  Por isso, sempre prefira usar tipos primitivos que são mais simples e rápidos ao invés dos wrappers pelos seguintes motivos:

  • Operações matemáticas com wrapper ocasionam degradação de desempenho, uma vez que disparam o autobox/unbox para cada operação.
  • Erros de NullPointException e complexidade desnecessária para comparação de igualdade usando equals.

Segue abaixo os únicos motivos que justificam o uso de primitivos wrappers, não é suportado como tipos primitivos:

  • Elementos chaves para collections.
  • Tipos parametrizados generics.
  • Com chamadas usando reflection.

Para todas as informações, veja o post inicial.

“Ainda que eu ande pelo vale da sombra da morte, não temerei mal nenhum, porque tu estás comigo; o teu bordão e o teu cajado me consolam.” Salmos 23:4

Programação – Item 48

Postado em

Não use dinheiro-real-moeda-cedula-curiosidadefloat e double para cálculos com respostas exatas

Os tipos float e double foram projetados para cálculos científicos usando aritmética binária de ponto flutuante, não fornecendo resultados exatos para cálculos monetários. Dessa forma, de preferência para uso de BigDecimal para cálculos comerciais monetários que demandem respostas exatas.

Para todas as informações, veja o post inicial.

“O SENHOR é o meu pastor; nada me faltará.” Salmos 23:1

Programação – Item 47

Postado em

software-testing-company-605Conheça e use as bibliotecas

Escrever uma biblioteca, componente ou framework com qualidade mínimas aceitáveis requer experiência e conhecimento do contexto, tempo hábil para desenvolvimento, testes e documentação, casos reais de aplicações. E para cobrir tudo isso, muito investimento financeiro.

Dificilmente uma corporação terá poder intelectual, recursos, mão de obra disponível e tempo para competir com a comunidade mundial. Sendo assim, nunca tente reinventar a roda! Prefira sempre usar uma biblioteca, componente, framework existente JCP ou até proprietários. Veja os benefícios:

  • Reutilizar conhecimento de especialistas que criaram e das experiências daqueles que usaram antes de você.
  • Evitar a perda de tempo criando soluções ad-hoc para problemas periféricos.
  • Evolução e melhoria da qualidade da biblioteca, componente, framework tende a melhorar ao longo de tempo quando a comunidade usa, avalia e sugere melhorias. Novos recursos serão adicionados a cada nova versão diante das novas necessidades emergentes.
  • Adotar na solução as tendências atuais, proporcionando uma manutenção mais fácil por diferentes desenvolvedores.

Não querendo criticar sua capacidade com profissional, mas a economia em escala já nos ensina há muito tempo que código de comunidade recebe uma atenção infinitamente maior do que a maioria dos desenvolvedores poderia dedicar a estas mesmas funcionalidades.

Para todas as informações, veja o post inicial.

“Porque para mim tenho por certo que os sofrimentos do tempo presente não podem ser comparados com a glória a ser revelada em nós.” Romanos 8:18

Programação – Item 46

Postado em Updated on

b7c21e65f85d4735f07051afcf70fe75Prefira loops com for-each aos tradicionais for

Loops usando o tradicional uso do for no qual o programador é o responsável por controlar a iteração e o índice são confusos e representam uma grande oportunidade de erros ocultos não validados pela compilação, principalmente em casos e loops aninhados. O novo loop for-each introduzido na versão 1.5 elimina toda essa confusão e as oportunidades de erros. Diante disso, de preferência ao uso no for-each. Segue abaixo os únicos casos nos quais é preferível usar o for tradicional, no qual o for-each não suporta:

  1. Quando se fez necessário alterar ou remover um elemento da matriz ou coleção durante a iteração.
  2. Quando existir múltiplos threads fazendo iterações usando a mesma referência em paralelo.

Para todas as informações, veja o post inicial.

“Porque o SENHOR Deus é sol e escudo; o SENHOR dá graça e glória; nenhum bem sonega aos que andam retamente.” Salmos 84:11