Design Patterns – Padrões de Projetos

Basicamente, trata-se de práticas consagradas para evitar proliferação de classes pelo sistema. Maneiras mais inteligentes para o agrupamento e reutilização dos objetos, trazendo soluções mais eficazes, eficientes e com menor consumo de memória (algumas vezes).

Bom, comecei a estudar este assunto não dando muito credibilidade em sua aplicabilidade. Cheguei a conversar com meu consultor de “reclamações aleatórias”, Denysson Mota (blog ao lado ->), sobre a verdadeira necessidade deste assunto em meu cotidiano, assunto este que nasceu nos idos de 1975 (não lembro ao certo), por um engenheiro civil, sabe-se lá o nome.

Ponto. Isso já mostra a ingrime curva de meu conceito quanto à aplicabilidade dos patterns: afirmo que TODO analista de sistema (que se preze) deve conhecê-los e saber aplicá-los.

Resumindo, para não estender o post, podemos dividi-los em 3 grupos: Criacionais (que trata de melhores mecanismos de instancias das classes), Estruturais (que trata da interação entre os componentes, fazendo com que trabalhem em conjunto, cada qual com suas atribuições, solucionando melhor as requisições) e Comportamentais (trata da comunicação dos componentes, trazendo mais dinamicidade na resposta da requisição). Enfim, cada qual com suas consagradas técnicas.

Citando algumas “técnicas”, ou melhor dizendo: Padrões, podemos iniciar com os criacionais factoryMethod (um componente que simula uma fabrica de classes, organizadas numa idéia de “switch”,  ligado a uma interface que determina todas as subclasses),  singleton (trazendo toda uma economia de instâncias, entende-se “static” ou “static final”) e abstract factory (um componente “singleton”, que não trata apenas um switch de classes, mas também as famílias destas classes), passando pelos estruturais decorator (extendendo um componente concreto e um abstrato, decorando classes de forma independentes), bridge (fazendo uma ponte do componente abstrato com uma interface de ações), facade (“feaçaid”, liga-se a um componente concreto, economizando repetitivas chamadas de funções de diversas classes) , flyweight (que pra mim é a junção da idéia do factory com brigde, genial, economia grande memória) e adapter (um tanto quanto confuso, mas tornando “maleável” interfaces obsoletas ligando-se a um componente adaptador que possa incrementar novas ações, existentes nas suas subclasses), indo parar nos comportamentais memento (ideia genial de “backup” de objetos), iterator (largamente utilizado no Java, agrupamento e busca de classes/objetos) e chains of responsability (provendo um escudo abstrato entre o cliente e o pacote de classes, através de uma requisição é possível buscar a classe correta, e não encontrando chama-se um “sucessor”, que por sua vez é um auto-relacionamento).

Bom, existem muito mais, cheguei a contar 25 padrões em algum livro.

Concluindo: O segredo é saber o propósito de cada um, e a solução que cada um provê ao seu negócio, enxugando o mundo de classes soltas, fazendo um encadeamento mais inteligente entre elas.

Até a próxima! \m/

Métricas – Complexidade Ciclomática (Java Cyclomatic Complexity)

E aí pessoal…tudo certo?

Hoje me deparei com uma métrica bastante utilizada na Engenharia de Software. Realmente achei bastante útil, e olhando para trás, vejo que muitas empresas, em que trabalhei, seriam bastante beneficiadas pelo conceito desta métrica.

Trata-se da Complexidade Ciclomática (CC). Uma métrica que calcula, basicamente, a complexidade de seu algoritmo, estabelecendo “pontos” para cada item “complexo” utilizado.

A CC tem níveis de “riscos”, onde podemos estabelecer que entre 1-10 um possível efeito colateral é baixo (5%), entre 11 e 20 baixo-moderado (10%), entre  21 e 30 é moderado (20%), entre 31 e 40 é moderado-alto (30%), entre 41 e 80 é alto (40%) e acima de 80 considerado muitíssimo alto (60%) e de certa forma não viável (Altamente complexo e não testável).

Tecnicamente falando:
Método da classe = 1pt (cada); if = 1 pt (para cada condição); for = 1 pt; while = 1pt; switch = 1pt (para cada case, lembrando que o default é zero), catch = 1 pt…enfim, não lembro todos .

Exemplificando no código (Java, mas poderia ser qualquer outra):
public boolean primo(int x){ // +1
if (x ==1 || x == 2) { // +2
return true;
}
int raiz = (int) Math.sqrt((double) x);
for (int i = 2; i <= raiz; i++){ // +1
if (x%i ==0){ // +1
return false;
}
}
return true;
}
}
Resultado: Complexidade ciclomática 5.

Para comunidade Java – Caso vocês estejam se perguntando como calcular a CC em sistemas grandes, então aqui vai uma dica, um plugin para o Eclipse, que mensura a complexidade de seu algoritmo: http://metrics2.sourceforge.net.

Dada a idéia, boas métricas para todos!!! =D