Convenções e Padrões - Java
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.
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
No momento só estou preocupado em conhecer a especificação.
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):
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);
Suporte a Eventos:
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.
Artigo completo (View Full Post)