Archive for the ‘Java EE’ 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.

JSF View Acion

quinta-feira, novembro 12th, 2015

 

When to use f:viewAction / preRenderView versus PostConstruct?

http://stackoverflow.com/questions/9844526/when-to-use-fviewaction-prerenderview-versus-postconstruct

unindexed foreign key columns

quinta-feira, maio 7th, 2015

O Hibernate não gera índices para as colunas de chaves estrangeiras, nos banco de dados Oracle e Postgres. No mysql por ser obrigatório ter índice na chave estrangeira o hibernate gera.

Referências

http://stackoverflow.com/questions/2970193/getting-hibernate-to-generate-indexes-on-foreign-keys

http://blog.pdark.de/2009/12/15/finding-unindexed-foreign-key-columns/

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