Programando em equipe – Parte2

Continunação

 

Programador procedural no mundo orientado a objetos:

* Reduza a visibilidade da classe – Nunca deixe público e exposto pela classe algo que somente está sendo usado por ela internamente (atributos e métodos). Quanto mais coisas públicas as classes possuírem, menos flexibilidade de manutenção ela terá.

* Use sobrecarga de métodos – Dê preferência à sobrecarga de métodos em vez de ficar implementando controle de lógica baseado na passagem de parâmetros.

* Longas listas de argumentos – Métodos com muitos parâmetros refletem em geral a falta de percepção de que está faltando a criação de um objeto que contivesse estes dados devidamente encapsulados, utilizado posteriormente como agregação.

* Classes sem métodos ou sem atributos – A classe é a expressão de um componente portador de características e comportamentos. Salvo em raros casos, na utilização consciente de design patterns.

* Reutilização de código – Na POO podemos reutilizar código de duas formas: por herança ou agregação. Sempre faça uma análise crítica no caso de qual utilizar, mantendo em mente de que a agregação é a forma mais flexível. Entretanto, existirão casos de herança (considere casos de classes abstratas). De forma alguma faça CTRL+C e CTRL+V nas classes por menor que seja a circunstância!

* Polimorfismo sempre – Use indiscutivelmente quando puder argumentos, variáveis, tipos de retornos polimórficos. Não existe nenhuma outra coisa na POO que ofereça mais flexibilidade e manutibilidade como a codificação polimórfica.

* Classes Enormes – Isso é uma das picaretagens mais feias que podem ser feitas contra o patrimônio OO!!! Nunca faça classes longas, cheias de métodos, resolvendo tudo……é o famoso canivete suíço. Passe um pente fino nas classes usando a SRP – Single Responsability Principle – na qual afirma que cada classe deve ser implementada para resolver apenas uma situação, uma responsabilidade! Busque a granularidade certa entres as classes do seu projeto, considerando, é claro, o escopo em questão.

* Métodos Enormes – Métodos grandes, cheios de controle de fluxo normalmente devem ser analisados e fracionados em métodos menores com visibilidades mais restritas.

* Abuso em Recursos Estáticos – Outra ofensa contra o patrimônio OO! Na POO não existem funções e variáveis globais perdidas no espaço mágico do mundo encantado! Tudo é objeto se relacionando com outro objeto através de seus estados e ações. Classes que apresentam abusos deste recurso expressam que o programador (autor) não conseguiu visualizar as abstrações e seus relacionamentos dentro do contexto da implementação. Recursos estáticos representam um escopo especial que é compartilhado por todos os objetos de uma classe e devem ser usados para satisfazer somente este caso.

* Nunca Reinvente a Roda – O Java tem 14 anos (desde 1995) de existência e apresenta uma série de recursos agrupados pelas plataformas. Fora isso, existem muitos produtos proprietários, open-source ou pagos e, por esse motivo, nunca tente elaborar ou inventar algo do zero antes de pesquisar a fundo! Porque na maioria dos casos você vai achar alguma coisa pronta (classe, componentes, framework, especificação, produto open-source ou proprietário pago com preço acessível) para resolver aquilo que você está necessitando!

* Encapsulamento – Sempre esconda as estruturas internas de uma classe e controle o acesso ao estado dos objetos através do encapsulamento usando a padronização JavaBean.

* Implemente as Regras Arquiteturais – Se uma classe é a última da hierarquia, declare como final!! Se um método não pode ser anulado, declare com final! Se um argumento ou variável não deve ser mudado, declare como final etc… Ou seja, impeça ou force polimorfismo, libere ou restrinja visibilidades em herança ou agregações. Entenda seu domain model e expresse-as no modelo de classes!

* Ciclo de vida dos objetos – Sempre programe pensando em cooperar com o coletor de lixo!! Ou seja, analise bem os escopos de criação dos objetos (estático, instância ou local) e os libere (atribuindo null para as referências) logo após verificar que não irá mais utilizá-los. Perceba que esta prática deixa o código claro e legível.

* Modere a Criação de Objetos – Sempre seja moderado na criação de objetos, nunca criando mais do que você precisa, sendo que o coletor de lixo é muito eficiente, mas não faz milagres. Quando possível, tente reusar os mesmos objetos reiniciando-os ao seu estado inicial. Analise cada new que você declarar!! Em aplicações de médio/grande porte isso pode resultar em uma grande economia e conseqüentemente performance.

Controlando condições excepcionais:

* Controle de Erros – Nunca use como controle de erros com retorno de booleano ou códigos de erros! Em Java existe uma mecânica padronizada chamada de tratamento de exceções. Lance exceções indicando as condições excepcionais, usando classes existentes no core do JSE ou não tenha receio de criar as suas próprias quando necessário.

* Propagação de Exceções – Nunca propague uma exceção ocorrida de dentro de uma camada lógica para fora da mesma, sendo que a outra camada cliente não deve conhecer detalhes internos de execução. Neste caso propague outras exceções mais significativas referentes ao contexto da camada/componente/classe ou serviço.

* Exceções Polimórficas – Nunca use o tratamento de exceções de forma polimórfica! Sempre encadeie os catch de todas as exceções, deixando o código claro e legível para o próximo programador amigão do peito!

* Comendo Exceções – Nunca faça um try sem colocar nada no catch! No mínimo, tem que existir uma impressão da lista do trace ou substitua, se possível, o try por um if identificando a condição.

* Fluxo de Controle em Exceções – Nunca use um try/catch como fluxo de controle!! Ou seja, não baseie nenhuma lógica condicional no controle de exceções. O próximo programador agradece a legibilidade do seu código.

Bom, pessoal, estas foram as “pérolas” que eu já peguei espalhadas por ai! A área de comentários fica livre para quem quiser complementar ou dar sua opinião. Para quem deseja realmente ter uma boa base sobre o assunto, sugiro a leitura e a prática do Java Code Convention e o livro Head First OOA&D – (em português Análise e Projeto Orientado a Objetos). 

fonte: fernando franzini – imasters

:: LUCIANA COSTA ::

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s