Java Efetivo
Criar e destruir objetos
Item 1: Considere métodos criadores estáticos ao invés de construtores
- Diferente de construtores eles tem um nome
- Não é obrigado a sempre criar um novo objeto com new, cada vez que é chamado.
- Pode retornar um objeto de qualquer subtipo do tipo de retorno. Ex.: Retornar uma interface com classes não publicas (API Collections); Service Provider Framework, JDBC.
- Reduz a verbosidade da criação de instancias de tipos parametrizados. (Na versão Java SE 7 não é mais necessário).
- Classes sem construtores public ou protected não podem ser instanciadas com subclasses.
- Na sua leitura ele não é tão fácil de distinguir quanto por construtores. Deve-se ter maior atenção no seu JavaDoc e atenção nos nomes dos métodos,
Item 2: Considere Builders quando se encontrar com muitos parâmetros de construção. Ex:
NutritionFacts cocaCola = new NutritionFacts.Builder(240,8).caloris(100).sodium(35).carbohydrate(27).build();
Item 3: Reforce a padrão Singleton com um construtor privado ou o tipo enum.
Item 4: Reforce objetos não instanciáveis com um construtor privado.
Item 5: Evite a criação de objetos desnecessários.
public Boolean isBabyBoomer() {
//Unnecessary allocation of expensive object
Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone(“GMT”));
}
public class Person {
private static final Date BOOM_START;
static {
Calendar gmtCal = Calendar.getInstance();
BOOM_START = gmCal.getTime();
}
}
}
Item 6: Elimine a referência a objetos obsoletos, não utilizados.
Métodos Comuns a todos os objetos
Item 8: Sobrescreva o método equals da maneira correta.
Item 9: Sempre sobrescreva o método hashCode quando sobrescrever equals.
Item 10: Sempre sobrescreva o método toString.
Item 11: Sobrescrever o método clone com muito cuidado e quando for estritamente necessário.
Item 12: Considere implementar a interface Comparable
Classes e Interfaces
Item 13: Minimize o acesso a classes e membros
As vezes não há necessidade de criar todas as classes como pública, ex. As classes do pacote das coleções, muitas classes utilizadas não são públicas.
Item 14: Em classes públicas utilize métodos e não campos públicos.
Item 15: Minimize a mutabilidade.
Item 16: Previra a composição ao invés da herança
Principalmente se herdar de classes de outra package
Item 17: Projete e documente para herança ou então proíba-a.
Item 18 – Prefira interfaces ao invés de classes abstratas.
Como a linguagem não permite herança de mais de uma classe isso pode se tornar uma limitação e além disso através de interfaces uma classe pode ser de vários tipos, chamado mixin.
Pode ser fazer uma combinação entre intrefaces e suas implementações em classes abstratas.
Item 19 – O uso de interfaces somente para definir tipos
O uso de interfaces para definir constantes é um péssimo exemplo de uso. A sugestão para definir constantes é utilizar uma classe estática utilitária, além de import estáticos para facilitar a programação.
Item 20 – Preferível utilizar uma hierarquia de classes do que classes que contenha um atributo que definam seu tipo, tagged classes
Item 21 – Utilizar funcion objects para representar strategies
Item 22 – Prefira membros de classes estáticas ao invés de não-estática.
Se declarar um membro de classe que não precise acessar a classe pai, sempre declarar como estática.
Generics
Item 23 – Não utilize tipos “crus” em códigos novos
Preferir a utilização de código utilizando generics como a classe List<E>.
Item 24 – Elimine os “unchecked warnings”
Evitar utilizar a sua anotação e se não for possível comentar e utilizar no mínimo escopo possível como numa variável local. Evitar no método e nunca utilizar no nível de classe.
Item 25 – Prefira listas ao invés arrays
Arrays são covariantes e listas não, isso garante segurança nos tipos de dados utilizados em tempo de compilação.
Item 26 – Prefira tipos genéricos
Tipos genéricos evitam exceção por tipo de classe quando se utilizam cast para forçar troca de tipo.
Item 27 – Prefira métodos genéricos
Para evitar o uso de cast no retorno do método. Aumenta a segurança do código, deixa mais claro e mais enxuto.
Item 28 – Utilize bounded wildcards para incrementar a flexibilidade da API
Ex: public método(<?extends E> param)
Utilizar a PECS – Producer extends, consumer super
Não utilizar wildcards para retorno. Pois o código de cliente também terá que utilizar.
Item 29 – Considere contêineres heterogêneos com tipos seguros
Ao invés de utilizar como nas classes de coleções, que fixam um tipo específico para sua utilização, ex: List<String> pode-se utilizar uma nova estratégia que define o tipo que será utilizado como parâmetro com a classe Class. Ex:
Pode-se ter um tipo como DatabaseRow representando uma linha da tabela (o contêiner no caso) e um tipo genérico representando a sua chave Column<T>. É um design mais sofisticado para não fixar o parâmetro fixo da classe contêiner.
Enums e Annotations
Item 30 – Utilize enum ao invés de constantes int
Muito mais legível e prático.
Item 31 – Utilizar campos de instância ao invés de ordinais
Melhor utilizar um atributo definido num enum, do que a sua ordem para representar alguma regra no programa.
Item 32 – Utilize EnumSet ao invés de campos de bits (bit fields)
Aliando a melhor funcionalidade de utilizar Enum aliada a funcionalidade de bit fields, não há necessidade de utilizar campos de bit fields.
Item 33 – Utilize EnumMap ao invés de indexação ordinal
Ao invés de utilizar o valor ordinal do Enum para um índice de array, por exemplo. Deve-se utilizar a estrutura de dados EnumMap.
Item 34 – Emule enums extensíveis com interfaces.
Pode-se criar uma interface para que um Enum implemente e assim trabalhar utilizando esta interface.
Item 35 – Prefira anotações ao invés de padrões de nomes
Utilizando reflexão podemos buscar uma definição utilizando uma anotação para verificação ao invés de utilizar uma padrão de nomes. Ex.:
@Test no métodos ao invés de testFuncio() como padrão de nome
Item 36 – Sempre utilizar s a anotação @Override
Evita BUGs no código, pois em tempo de compilação verifica-se que deve se sobrescrever o método em questão.
Item 37 – Utilize interfaces marcadoras para definição de tipos
Mesmo não tendo métodos uma interface pode ser utilizada para definir um tipo, chamada de interface de marcadora. Em outros casos pode-se utilizar uma anotação de marcação. Mas sempre quando se refere-se a um tipo deve se utilizar um interface de marcação.
Métodos
Item 38 – Valide os parâmetros
Item 39 – Faça cópias de segurança quando necessário
Faça uma cópia defensiva para cada parâmetro mutável que o construtor possui.
Item 40 – Design assinaturas dos métodos cuidadosamente
– Escolha do nome do método bem feita
– Não exagera no número de métodos, por exemplo, numa interface.
– Evitar uma longa lista de parâmetros
– Melhor utilizar interfaces do que classes para parâmetros que se refiram a tipos.
– Prefira uma enum com dois tipos do um boolean como parâmetro
Item 41 – Utilize sobrecarga de metódos, overloanding, com cuidado.
Overloading, sobrecarga de métodos é decidido em tempo de compilação. Já o overriding que é a sobrescrita dos métodos nas classes filhas é feito em tempo de execução.
Dica: nunca tenha dois métodos de sobrecarga com o mesmo número de parâmetros, somente se eles tenham exatamente o esmo comportamento.
Item 42 – Utilize varargs com cuidado.
Utilizar somente em casos em que necessite passar um número variável de parâmetros.
Item 43 – Retorne arrays ou coleções vazias ao invés de null.
A classe cliente não precisar utilizar dois testes para saber se a coleção esta vazia.
Item 44 – Faça documentação de todas as APIs expostos, ou seja, estão como publico.
Programação em Geral
Item 45 – Minimize o escopo das variáveis locais. Só instancie uma variável local quando for utilizá-la.
Item 46 – Preferia for-each loops do que os loops tradicionais. A não ser que o tenha que trabalhar sobre a coleção em questão como remoção.
Item 47 – Conheça e use as bibliotecas padrões do java, ao invés de criar as suas
Item 48 – Evite utilizar double e float para resultados exatos. Como valores financeiros. Até 9 dígitos utilize int, até 18 long e após isso BigDecimal.
Item 49 – Prefira tipos primitivos ao invés das classes wrapper de primitivos. Muito cuidado para utilizar comparações com entre wrapper.
Item 50 – Evite Strings onde outros tipos são mais apropriados.
Item 51 – Evite a concatenação de strings, utilize StringBuilder.
Item 52 – Referencie objetos pelas suas interfaces.
Item 53 – Prefira interfaces pra reflexão.
Item 54 – Utilize métodos nativos com cuidado.
Item 55 – Otimize cuidadosamente
Não sacrifique a arquitetura em função de performance.