Convenções e Padrões - Java

Observo no cenário de IT, de forma generalizada, um comportamento comum, um “modus operandi” dos fornecedores de tecnologia: Todos prometem ganho de produtividade, robustez, escalabilidade, interoperabilidade e etc. como se essas features fossem exclusivamente elementos pertinentes aos seus domínios. Sendo somente eles conhecedores, tanto do “por que”, quanto da solução, do problema. Além do fato que, obviamente, antes deles ninguém jamais mencionou nada a respeito. Enquanto isso ... em “Gotham City”, (na vida real, na prática,) quase tudo que um promete, jurando exclusividade, é exatamente a mesma coisa que o outro garante só ele oferecer ao mercado. Hehhheeh ... seria até engraçado se não fosse trágico.
O que não é nada legal nesse cenário, é a parte que nos cabe. Os consumidores dessas tecnologias, analistas e desenvolvedores, nós que sempre ficamos com a impressão de que compramos meio quilo de Manjuba a preço de Haddock. Acho que posso melhorar a metáfora: A propaganda nos faz sonhar com Badejo, logo pedimos dois quilos. Contudo, o produto que recebemos é Manjuba, meio quilo, pelo qual pagamos preço de Haddock.

Por exemplo, nos atendo somente ao que tange a conceitos (abstraindo as questões financeiras implicadas): Figura comum certo estereótipo “tech-evangelistas”, pregam a orientação a objetos com tal ortodoxia que quase chegam a convencer que eles são os únicos no mundo que possuem o mérito de ousar falar sobre o assunto sagrado. Eles apresentam então, um mito de proporções colossais, mistério revelado somente aos sacerdotes iniciados por decorrência de uma eleição divina. Divindade essa que só eles conhecem, suponho ... hehehehee!!!
Tudo bem, vou desconsiderar, neste momento, se o conteúdo das pregações é aderente ou não. Suponha que não seja relevante se alguém aprende OO. Muito ou pouco, não importa agora. O que eu acho intrigante é que toda “hermenêutica” desses pseudo-pregadores (normalmente de tecnologias que estão na moda) não difere uma vírgula, no que diz respeito ao cerne do conceito, da abordagem a orientação a objetos por outras tantas tecnologias. Entretanto, apesar disso, muitos deles exalam aquele tom ex-cathedra quando o assunto está em pauta. Conseqüentemente, contrastam pateticamente com o que intencionam esforçadamente aparentar. O pior de tudo é que acabam sendo aceitos como referência por muitos outros profissionais. Lamentável ....
Para finalizar o “momento desabafo”, quando o assunto é padronização e convenções, semelhantemente acontece a mesma coisa. Cada um fala de padrões como se fossem os únicos a terem consciência da relevância da adoção dos mesmos.

Uma pesquisa divulgada pela Sun alerta que ao longo da vida útil de um sistema, 20% do esforço será despendido na criação e no teste do código original. Ao passo que, 80% do esforço será despendido posteriormente na manutenção e em melhorias subseqüentes que sofrerá o software. Visto isso, (em primeiro lugar vamos fingir que somente a Sun detectou esse fenômeno, portanto prossigamos ...) é imperativo considerar que programar usando um conjunto de padrões ajuda a diminuir o esforço envolvido em testar, fazer a manutenção e melhorar qualquer código. Por isso, a Sun criou um conjunto de padrões de programação para Java, e publicou esses padrões num documento inteligentemente chamado de "Convenções de Código ]ava", que você pode encontrar em java.sun.com. É um documento, curto e fácil de ler, que recomendamos enfaticamente.

OBS: Obviamente essa questão de padronização é relevante para qualquer outra linguagem de programação. Por exemplo, no caso do Delphi, a Borland (fabricante original da ferramenta) padronizou e recomenda um padronização para codificação de um programa em Delphi.

Classes e Interfaces: A Primeira letra deve ser maiúscula. No caso de nomes que sejam palavras compostas, a primeira letra de cada palavra deve ser maiúscula.
No caso de classes o nome deve ser sempre um substantivo. Exemplo:

 EstacaoZnDummyClasse
 AutomovelEsportivo
 Automovel

No caso de Interfaces o nome deve ser adjetivos. Exemplo:

 Runnable
 Serializable

Métodos: A primeira letra sempre em caixa baixa. No caso de palavras compostas, a primeira letra sempre em caixa baixa, as demais palavras seguintes iniciam por letra maiúscula. Além disso, os nomes dos métodos devem sempre ser uma composição par de palavras: a primeira um verbo, seguindo de um substantivo. Exemplo: “playSong();”, “getName()”.

Variáveis: quanto a caixa, segue a mesma lógica que os métodos. Inicia com letra minúscula. No caso de palavras compostas, a primeira letra sempre em caixa baixa, as demais palavras seguintes iniciam por letra maiúscula. Não devemos usar verbo para nomear variável. Exemplo: largura (width), cor (color), nome (name).

Constantes: As constantes Java são criadas marcando-se variáveis como estáticas e finais. Elas devem ser nomeadas usando-se letras maiúsculas com caracteres underscore como separadores. Exemplo: “INDICE_ECONOMICO”, “A_NAME_PATH_PRG”.

Padrões JavaBeans

No momento só estou preocupado em conhecer a especificação.

No livro da Kathy Sierra, ela refere-se a especificação JavaBeans como uma padronização para reuso de componentes, vejamos:
Os ambientes integrados de desenvolvimento, chamados por IDE, objetivam facilitar o desenvolvimento de softwares. Provendo maior produtividade e gerenciamento dos projetos. A especificação JavaBeans criada para ser um padrão para o desenvolvimento de componentes, os quais possam ser facilmente usados por outros desenvolvedores numa IDE. Seja para o NetBeans ou para o Eclipse, é possível adquirir componentes de terceiros que facilitem a implementação do seu projeto. Usar regras de nomeação JavaBeans é a forma de garantir que outras ferramentas poderão reconhecer e usar componentes cridos por desenvolvedores distintos. O conhecimento da API JavaBeans é fundamental para o exame de certificação.

Encontrei uma definição na web que define: Javabean é um componente de software reusável, normalmente usado em aplicações standalone e applets. Descando como principais característas: Instrospecção, customização, eventos, propriedades e persistência.

Vejamos o que a Kathy fala sobre propriedades:
Propriedades são variáveis de instância privadas. Portanto a única forma de comunicação entre elas e o mundo exterior é através de métodos públicos que funcionem como uma interface entre essas variáveis e o mundo externo a classe. Logo, a especificação JavaBean precisa de dois métodos para permitir acesso as propriedades da classe: Um para atribuir valor e outro para recuperar valor. O método cujo a função é permitir atribuição de valor para a variável privada é chamado de “setter”. Enquanto que o método que permite recuperar o valor de uma propriedade é chamado de getter.

Regras para nomeação de propriedades JavaBean que são argüidas no exame de certificação (segundo o livro da Kathy Sierra):

O Prefixo para qualquer método getter deve ser “get”, exceto no caso de propriedades cujo o tipo é booleano. Neste caso é permitido tanto “get” como prefixo, como também “is”. Exemplo:

 getNomeCliente();
 getTituloComposicao();
 getTotalVenda();  
 IsPlaying() ou getPlaying(); // propriedade booleana.
 IsEmpty();// propriedade booleana.

Para qualquer método “setter” (atribuidor de valor), o prefixo deve ser “set”. Exemplo:

 setNomeCliente(String Nome);
 setTituloComposicao(String Composicao);
 setPrecoCompra(Double Valor);

Para compor o nome de um método, “getter” ou “setter”, completo, passe a primeira letra do nome da propriedade para maiúscula em seguida adicione o prefixo apropriado (“get”, “is” ou “set”).

As assinaturas de métodos “setter” devem ser marcadas como públicas, o tipo de retorno é sempre “void”. Além disso um argumento que represente a propriedade (do mesmo tipo da propriedade).

As assinaturas de métodos “getter” devem ser marcadas como públicas. Não existem argumentos. Todavia, devem ter um tipo de retorno compatível com a propriedade em a qual ele se propõe recuperar o valor.

Suporte a Eventos:

A especificação JavaBean se propõe a suportar eventos. Desta forma permitindo aos componentes notificarem uns aos outros quando algo acontece. Semelhante ao conceito extensivamente conhecido pelos programadores Delphi desde a versão um da ferramenta, o modelo de eventos JavaBeans freqüentemente é usado em aplicações GUI. Por exemplo, quando um evento qualquer, como um clique do mouse, é comunicado para muitos outros objetos, esses outros objetos podem executar ações quando isso ocorrer (Oh!!! hehehe). Os objetos que recebem a informação de que ocorreu um dado evento são chamados de listeners. Para o exame, você precisa saber que os métodos que são usados para adicionar ou remover listeners de um evento devem também seguir padrões de nomeação JavaBean:

Regras de Nomeação de Listeners JavaBean:

Os nomes de métodos listeners usados para "registrar" um listener como uma fonte de eventos devem usar o prefixo “add”, seguido do tipo do listener. Por exemplo: addActionListener ().

Nomes de métodos listeners usados para "desregistrar", ou seja remover, um listener devem usar o prefixo “remove”, seguido do tipo do listener (usando-se as mesmas regras que o método add de registro).

O tipo de listener a ser adicionado ou removido deve ser passado como o argumento para o método.

A seguir, exemplos de assinaturas de métodos JavaBean válidas:

 // método setter
 public void setValueZn(int value);

 //método getter
 public int getValueZn();

 // Métodp getter
 public boolean isZnUpdated();

 // Removendo o listener
 public void removeMyListener(MyListener m)

 // Adicionando um listener para dar a classe suporte a eventos
 public void addZnListener(ZnListener AZn)

Exemplificando de assinaturas de métodos JavaBean inválidos:

 void setCustomerZn (String sZn); // Ausência da palavra reservada “public”

Um método setter tem que ser declarado como público

 public void modifyZnValue(int vZn); // Uso da palavra reservada modify não
 é  permitido

 public void addYnxListener(ZnListener xZn); //Tipo do listener incompatível

 public void getZnPostNUmber(int znNumber); // um método getter que não retorna
  nada e possui argumento.