Arquivos | Java Effective RSS for this section

Exceções – Item 57

2153Use cada tipo de exceção corretamente

A linguagem Java fornece três tipos diferentes de criação de exceções, cada uma para um fim específico:

  1. Checadas – usadas para situações em que o chamador tenha condições de se recuperar.
  2. Não Checadas – usadas para indicar erros de programação.
  3. Erros – usadas exclusivamente pela JVM para indicar deficiências em recursos e falhas em invariantes que tornem impossível continuar a execução da solução.

Sendo assim, use as exceções “Checadas” caso julgar que a condição é recuperável, senão use exceções de “Não Checadas” para definir erros de programação. Não crie nenhuma exceção do tipo “Erros”, uma vez que elas são por convenção reservadas exclusivamente para condições de erros da JVM.

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

“O caminho de Deus é perfeito; a palavra do SENHOR é provada; ele é escudo para todos os que nele se refugiam.” Salmos 18:30

Exceções – Item 56

consolidated-dont-do-it-deck-7875-p2326-5324_zoomSó use exceções em condições excepcionais

As exceções foram projetadas para fazer sinalização de condições excepcionais. Portanto, não use exceções para controle de fluxo e não crie API que forcem os outros a usarem com controle de fluxo.

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

“A resposta branda desvia o furor, mas a palavra dura suscita a ira.” Provérbios 15:1

Programação – Item 56

txtAdote convenções de nomeação geralmente aceitas

A plataforma Java tem um conjunto bem estabelecido de convenções de nomeação para criação dos elementos de programação: pacotes, classes, interfaces, anotações, tipos genéricos, métodos, campos e variáveis. Raramente esses padrões devem ser violados e nunca sem uma boa razão. Segue as consequências de violar essas convenções:

  1. API fica difícil de ser utilizada.
  2. API fica difícil de ser alterada.
  3. Confundir e irritar os programadores usuário da API.
  4. Podem causar suposições falsas resultando em erros.

Diante disso, aprenda as convenções de nomeação padrão da plataforma Java e use com bom senso. Segue o link do Java Code Convention.

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

“Filhinhos, não amemos de palavra nem de boca, mas em ação e em verdade.” 1 João 3:18

Programação – Item 55

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

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

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

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

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

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

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

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 631 outros seguidores