Archive for the ‘Java SE’ Category

Java Efetivo – Effective Java (Joshua Bloch)

domingo, fevereiro 7th, 2016

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.

Item 7: Evite finalizers

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.

Supero Way*

sábado, maio 25th, 2013

*Nome sugerido pode mudar

É o modo de desenvolver softwares utilizando frameworks e soluções open-sources. Abrange todo o ciclo de desenvolvimento de um software com objetivos claros de produtividade e qualidade.

 

GOALS
– Não é uma definição de regras e imposição do modo de desenvolver softwares
– Evita atividades manuais com copy/paste para desenvolver novas funcionalidades
– Ferramentas conhecidas e amplamente utilizadas pela comunidade open-source
– Automatização e geração de código limpo e sem lixo para CRUD e é facilmente customizável.
– O projeto gerado é um full complice java EE 6, ou seja, é o PADRÃO para aplicações java corporativas.
– O desenvolvedor tem o foco em atender o cliente e na solução do negócio e não na infraestrutura e na integração de várias tecnologias
É composto de:

IDE
Eclipse + JBoss Tools ou Jboss Developer Studio
Ferramenta Forge com scaffold, ou seja, geração de telas e operações CRUD.

JavaEE 6 PURO!
Isto é (JPA2, EJB3, CDI1.0, JAX-RS, JAX-WS, JSF2)
JPA2 – Persistência em banco de dados.
EJB3 – Regras de negócios, operações transasionais, segurança, pool de recursos
CDI1 – Inversão de controle, contexto e injeção de dependência.

JAX-RS – Web services RESTfull

JAX-WS – Web services SOAP
JSF2 – Apresentação com JSF
Primefaces – Extensão do JSF, biblioteca com vários componentes
JQuery-Mobile – Camada de apresentação para o navegador de móbiles.

ALM (Application Lifecycle Management)
Redmine – Gestão de projetos, requisitos e bugs
Maven – Builder, construtor padrão da aplicação, independente de IDE
Nexus – Gestão de componenetes de software, não apenas de tela mais de negócio. Modularidade das aplicações e retulização.
Jenkins – Builder da aplicação, agendador de validação do builder, testes automatizados e inspeção de código integrado com o sonar.
Sonar – Inspeção de código, checkstyle, findbugs, etc. Chamado e integrado pelo Jenkins

Testes
Junit + Arquiliam

 

O mais legal do Java

sábado, março 23rd, 2013

Muitos podem dizer que o mais legal do Java é linguagem de programação, outros a característica de rodar numa máquina virtual e ser multi-plataforma, ou então por ser amplamente utilizada e aberta, ou até mesmo pela riqueza de bibliotecas, APIs e frameworks. Mas eu digo que é outro fator, a sua organização. Quero falar um pouco de algo que pouca gente sabe, principalmente para os iniciantes e para quem não esta muito envolvido com o ambiente Java. Que é comunidade dos desenvolvedores da especificação da tecnologia Java, ou seja, a JCP (Java Community Process).

A JCP é a comunidade que define todo o futuro e evolução da tecnologia Java, no qual não é possível falar dela sem falar da JSR (Java Specification Request). Que nada mais é do que a especificação de uma funcionalidade, característica que plataforma Java deve possuir. Ou seja, a plataforma Java nada mais é do que uma composição de várias JSRs. Por exemplo, a JSR 220 possui toda a especificação da EJB 3.0, ou seja, é um documento contendo tudo o que o EJB 3.0 possui e mais uma implementação de referência. Um paralelo na orientação a objeto seria:  a JSR definiria a interface, a implementação de referência seria uma classe que nós implementaríamos de referência, e todos os servidores de aplicação com EJB 3.0 teriam que implementar esta interface.

E tudo que o Java possui, considero que isto é o mais legal do Java.  Ou seja, é uma comunidade livre, aberta e quem tiver interesse pode participar e até mesmo abrir uma JSR ou liderar uma. E cá entre nós, acredito que esse é o segredo do grande sucesso e da ampla utilização da plataforma Java pelo mundo.

Só para você ter uma ideia do poder da JCP, entre os membros do comitê executivo, estes membros são quem votam e escolhem quais são as JSRs que entrarão nas próximas versões e evoluções da tecnologia Java estão gigantes como: HP, IBM, Intel, Nokia, Oracle e SAP.

Aqui tem alguns dos membros da comunidade, e da pra ver que ela é composta por profissionais com muita bagagem, muita experiência e que trabalham em grandes empresas que são fornecedoras de tecnologia. E o mais importante, são de VÁRIAS empresas, é uma comunidade, quem quiser pode abrir uma JSR e várias empresas votam em prol da evolução do Java, o seja, não é algo fechado e definido internamente por uma única empresa.

Enfim, é isso que eu acho o mais legal do Java, ela é aberta, em constante evolução e praticamente formada por um consórcio de empresas e profissionais engajados na sua evolução. E além de tudo isso, É DE GRAÇA!

 

abraços,

Tadeu Gois

Java code conventions

sábado, março 16th, 2013

Meu primeiro post é sobre um tópico não muito valorizado e pouco discutido, pelo menos nas equipes no qual trabalhei, que é sobre convenção do código Java.

Acho que todo desenvolvedor Java, antes mesmo de começar a escrever uma linha de código, deveria ler esta documentação de padronização. O documento em PDF pode ser acessado por http://www.oracle.com/technetwork/java/codeconventions-150003.pdf . e é a convenção que o pessoal da SUN, criadores do Java,  seguiam e recomendavam. Abrange nomes de arquivos, organização de arquivos, recuo, comentários, declarações, espaço em branco, convenções de nomenclatura, as práticas de programação. Além de um exemplo de código.

Como mesmo diz no próprio site da Oracle que fala sobre estes padrões http://www.oracle.com/technetwork/java/codeconv-138413.html ,

– 80% do custo do tempo de vida de uma peça de software vai para manutenção.

– Dificilmente qualquer software é mantido por toda a sua vida pelo autor original.

– Convenções de código melhoram a legibilidade do software, facilitando o entendimento para os desenvolvedores no novo código. Ou seja,  um entendimento mais rápido e completo.

Portanto, não é difícil conhecer estas convenções, pode ser um pouco chato no início, mas com certeza vale a pena. Depois que acostumar a ler um código nesses padrões, quando você encontrar um código que esta fora das convenções você vai achar ele muito bagunçado e até mesmo um pouco sujo. Além do que, o documento esta bem escrito e abrange praticamente todas as situações possíveis e com um exemplo bem completo de código no final do documento.

 

abraços,

Tadeu Gois