1) Criando e destruindo objetos – Java efetivo

Assim como os resumos que fiz em relação ao livro de certificação, tenho feito resumo de outros materiais ao qual irei gerando novas postagens e publicando aqui no blog.

O livro Java Efetivo, de Joshua Bloch, também tenho feito resumos.
Neste post irei colocar um resumo do primeiro capítulo do livro “Java Efetivo – segunda edição revisada” da Editora Alta Books.

Obs: É de suma importância a leitura por completo do livro para melhor entendimento do contexto em geral.

1) Considere o uso de métodos de fabricação estáticos em vez de construtores

– Além da forma básica que conhecemos de provermos uma instância da classe através de um construtor público, uma outra técnica interessante, é um método de fabricação estático público.
– Método de fabricação estático não é o mesmo que o padrão Factory Method de Design Patterns.
– Vantagens do uso de métodos de fabricação estáticos:
– Diferente dos construtores, eles têm nomes;
– Métodos de fabricação estáticos não precisam criar um novo objeto sempre que são chamados. (Isso permite que classes imutáveis usem instâncias pré-construídas, ou armazenem em cache as instâncias ao serem construídas). Com isso, há uma melhora grande no desempenho se objetos equivalentes dorem solicitados com frequência.
– Diferente dos construtores, eles podem retornar um objeto de qualquer subtipo de seu tipo de retorno.
– Reduzem a verbosidade na criação de instâncias de tipo parametrizados.
– Desvantagens no uso de métodos de fabricação estáticos:
– Classes sem construtores públicos ou protegidos não pode ter subclasses. (Porém, isso pode ser uma vantagem, já que encoraja os programadores a usarem a composição em vez da herança.)
– Não é possível distinguí-los imediatamente de outros métodos estáticos que sua classe venha a ter.

2) Considere o uso de um objeto criador quando se deparar com muitos parâmetros de construção

– É uma variação do padrão Builder do Design Patterns.
– Em vez de criar o objeto desejado diretamente, o cliente chama um construtor (ou método de fabricação estático) com todos os parâmetros obrigatórios e obtém um objeto criador. Em seguida, o cliente chama métodos tipo setter no objeto criador para configurar cada parâmetro opcional de interesse. Para concluir, o cliente chama o método ‘build’ sem parâmetros para gerar o objeto, que será imutável.

3) Imponha a propriedade Singleton com um construtor privado ou um tipo enum

– Singleton é simplesmente uma classe que é instanciada apenas uma vez.
– Para tornar Serializável um classe Singleton, não basta apenas implementar Serializable. Para preservar a propriedade Singleton (apenas uma instância da classe), terá que declarar todos campos de instância como transientes e fornecer um método readResolve.
– Conforme descrito no livro, “um tipo enum com apenas um elemento é a melhor maneira de implementar um Singleton”

4) Imponha a não-instanciação com um construtor privado

– O uso dessa forma, deve ser utilizadas em classes onde não foram projetadas para serem instanciadas, como é o caso de classes utilitárias.
– Na ausência de construtores, o compilador fornece um construtor padrão. Porém, como dito, algumas classes não servem para ser instanciadas, por isso, devemos então, ter apenas um construtor privado e essa classe torna-se não-instanciável.

5) Evite a criação de objetos desnecessários

– “Geralmente é apropriado reutilizar um objeto individual em vez de criar um novo objeto funcionalmente equivalente sempre que ele é necessário. A reutilização pode ser mais rápida e ao mesmo tempo mais elegante. Um objeto poderá ser sempre reutilizado se for imutável.”

6) Elimine referências de objeto obsoletas

– “A anulação de referências de objeto deve ser a exceção e não a regra.”
– “Sempre que uma classe gerenciar sua própria memória, o programador deve ficar alerta a vazamentos de memória.”
– Um vazamento de memória comum são os listeners e outros retornos de chamadas.

7) Evite finalizadores

– “Os finalizadores são imprevisíveis, com frequência perigosos e geralmente desnecessários.”
– No livro, consta algumas explicações porque não devemos utilizar finalizadores, dentre estes, temos: “há uma grave perda no desempenho”, “nunca devemos depender de um finalizador para atualizar um estado persistente crítico” entre outros. Em resumo, “os finalizadores têm alguns (2 para ser mais específico) usos válidos, mas como regra prátiva, você deve evitá-los”.

Principal referência:
BLOCH, Joshua. Java Efetivo – Segunda edição revisada. Rio de Janeiro: Alta Books Editora, 2008.

Valeu pessoal! =D

Anúncios

Obrigado pelo comentário.

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s