Java Effective

Serialização – Item 78

Postado em Atualizado em

Considere o uso de proxies de serialização em vez de instâncias serializadas

O Item 75, 76 e 77 expôs os possíveis de erros que podem prejudicar o uso de classes serializadas e seus contras medidas. Outra forma existente de contornar todas essas situações é usando o padrão de “proxies de serialização” que usa uma classe estática interna privada responsável por representar concisamente o estado lógico da classe delimitadora a ser serializada. O padrão contorna todos os erros de (invariâncias, ataque de fluxos inválidos e duplicações de singleton) sendo a maneira mais fácil e robusta de se serializar um objeto.

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

“Deus não é injusto. Ele não esquece o trabalho que vocês fizeram nem o amor que lhe mostraram na ajuda que deram e ainda estão dando aos seus irmãos na fé.” Hebreus 6:10

Serialização – Item 77

Postado em Atualizado em

Para o controle de instâncias, prefira tipos enum a readResolve

O recurso do readResolve contorna aparentemente a possível criação de outro objeto de um singleton serializado, mas na verdade ainda fica aberto para erros caso algum invasor retenha uma referência ao abjeto antes de seu método readResolve ser invocado. Portando, use tipos enum para a imposição de invariáveis de controle de instância. Dessa forma existira uma garantia solida que não haverá instâncias além das constantes declaradas, gerenciados automaticamente pela própria JVM.

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

“Eu sou a videira, e vocês são os ramos. Quem está unido comigo e eu com ele, esse dá muito fruto porque sem mim vocês não podem fazer nada.” João 15:5

Serialização – Item 76

Postado em

batterdispenserCrie métodos readObject defensivamente

Sempre que você criar um método readObject, assuma a atitude de quem está criando um construtor público que tem que fornecer uma instância válida, independente do fluxo de dados a receber. Não assuma que o fluxo de bytes representa uma instância serializada real, uma vez que o ele pode ser maliciosamente manipulado. Portanto, mantenha a mesma política de um construtor validando os argumentos (Item 38), usando copias defensivas de parâmetros onde apropriados (Item 39) e não invocando métodos abertos para polimorfismo. Isso impedira qualquer violação de invariância.

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

“..sintam-se felizes quando passarem por todo tipo de aflições. Pois vocês sabem que, quando a sua fé vence essas provações, ela produz perseverança.” Tiago 1:2-3

Serialização – Item 75

Postado em Atualizado em

21165_xxx_v1Considere o uso de uma forma serializada personalizada

Quando você decidir que uma classe deve ser serializável (Item 74) pondere bem que forma serializada ela deve ter. Não aceite a forma serializada padrão sem antes considerar se ela é apropriada para a determinada classe. Use a forma padrão somente se ela for uma descrição correta do estado lógico do objeto. Caso contrário, projete uma forma serializada personalizada adequada contendo suas particularidades de compatibilidades. A seleção da forma serializada errada pode ter impacto negativo permanente sobre a complexidade e o desempenho de uma classe.

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

“Pois existe um só Deus e uma só pessoa que une Deus com os seres humanos — o ser humano Cristo Jesus…”1 Timóteo 2:5

Serialização – Item 74

Postado em

serializacao-rastreabilidade-medicamento-rdc-54-2013Implemente Serializable Criteriosamente

A definição de uma classe serializável constitui um compromisso sério que deve ser adotado com cuidado. Uma vez feito, o autor da classe está assumindo o compromisso de evoluir as novas futuras versões, garantindo compatibilidade de serialização retroativa. Uma classe serializável apresenta as seguintes desvantagens:

  1. Diminui a flexibilidade de evolução, uma vez que o autor é responsável por dar suporte para serialização retroativa. Em alguns casos pode até impedir novas implementações por falta de compatibilidade.
  2. Altas cargas de testes no lançamento de uma nova versão da classe para garantir suporte para serialização retroativa.
  3. Aumenta a probabilidade de invariância, uma vez que é fácil esquecer-se de assegurar o estado consistente na reconstrução do objeto serializado.

Portanto, a facilidade de usar serializable é ilusória e não é uma decisão a ser tomada superficialmente.

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

“Portanto, vistam-se de misericórdia, de bondade, de humildade, de delicadeza e de paciência.” Colossenses 3:12

Concorrência – Item 73

Postado em

avoid-running-into-walls-step-7Evite o uso de grupos de thread

A classe “ThreadGroup” foi criada com funcionalidades bem limitadas e com muitas falhas. Ela se encaixa melhor na categoria de experimento mal sucedido. Portanto, considere a obsoleta e evite o seu uso. Caso existe a necessidade de trabalhar com grupos lógicos de threads (pooling), prefira o uso da API ExcecutorService da java.util.concurrent.

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

“Estou certo de que o SENHOR está sempre comigo; ele está ao meu lado direito, e nada pode me abalar.”Salmos 16:8

Concorrência – Item 72

Postado em

downloadNão dependa do agendador de thread

Nunca crie programas que dependa do agendador de threads para se funcionar corretamente. O programa resultante não será robusto e nem portável. Portanto, não depende de Thread.yield() ou das prioridades das Threads. Estes recursos são apenas “dicas” para o agendador da JVM, não tendo garantias de execução. As prioridades das Threads podem ser usadas para melhorar a qualidade de um programa já funcional, mas nunca devem ser utilizados para corrigir os erros graves de um programa mal elaborado.

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

“Deus nos salvou e nos chamou para sermos o seu povo. Não foi por causa do que temos feito, mas porque este era o seu plano e por causa da sua graça.” 2 Timóteo 1:9