Qualidade de Software: Princípios de projeto - Parte VII

segunda-feira, 8 de junho de 2009

Princípios de projeto - Parte VII - Coesão

Já conversei com algumas pessoas que utilizaram esta frase, "receita de bolo", quando eu perguntei o que significava, um bom design OO:

Baixo acoplamento e alta coesão.

Mas, o que é coesão de classe?

Este artigo é totalmente baseado no livro Fundamentals of Object-Oriented Design in UML, do Page-Jones.

Coesão de classe é a medida da inter-relação dos recursos (atributos e operações) localizadas na interface externa de uma classe. Page-Jones, diz que o termo coesão de tipo seria uma definição melhor, já que o conceito que está sendo passado aqui é: quão bem uma classe funciona como uma implementação de algum tipo de dado abstrato.

Ainda segundo Page-Jones, uma classe com baixa (ruim) coesão tem um conjunto de recursos que não estão em harmonia entre si. De outro modo, uma classe com alta (boa) coesão, tem um conjunto de recursos onde todos contribuem para a abstração de tipo implementada pela classe.

Algumas pessoas tem tentado definir coesão de classe considerando como os métodos usam os atributos internos. Entretanto, Page-Jones não gosta dessa definição por dois motivos: O primeiro é que a coesão de classe deve ser percebido de fora de uma unidade de software; o segundo é porque a coesão pode mudar de acordo com mudanças na classe durante o seu ciclo de vida, isto é, uma classe imatura pode parecer ter menor coesão que uma classe mais madura.

Page-Jones observou 3 problemas principais na alocação de recursos numa classe: mixed-instance, mixed-domain e mixed-role. Os problemas estão listados em ordem de relevância, sendo a mixed-instance o maior problema e mixed-role o menor.

Uma classe sem esses três problemas de coesão é inteiramente coesiva e pode-se dizer que possui uma coesão ideal.

Vamos as definições.

Mixed-instance: Uma classe com mixed-instance cohesion possui alguns recursos que não são definidos para alguns objetos da classe. Ex: em um departamento de vendas, existem vendedores comissionados e não comissionados. Uma classe Vendedor possui o método pagarComissao(). José é comissionado e Maria não. Poderíamos até setar a comissão de Maria para zero. Entretanto, isso não seria verdade, já que Maria não tem zero de comissão. Poderíamos criar um atributo boolean que indicaria se o vendedor é comissionado, mas isso seria um péssimo design. A solução mais elegante seria criar uma classe VendedorComissionado e VendedorNaoComissionado;
Mixed-domain: Uma classe com mixed-domain cohesion contém um elemento que sobrecarrega a classe com uma classe extrínseca de um domínio diferente. Uma classe A é extrínseca de B se A puder ser totalmente definida sem noção de B. Ex: Uma classe Real possui um método arcTan. Mas arcTan não é um recurso de Real e sim de Angle. Quando você está modelando uma classe de um dado domínio, você só poderá incluir classes dos domínios inferiores. É o que define reusabilidade.
Mixed-role: Uma classe contém um elemento que faz parte do domínio, mas não faz parte da abstração dessa classe. Ex: Uma classe Pessoa possui um método qtdCachorros(). Só que Cachorro, na verdade, não faz parte de Pessoa. Como você reusaria Pessoa se não houver Cachorro na nova aplicação? E se continuássemos com essa filosofia de design? Onde pararíamos? qtdBarcos(), qtdGatos(), qtdCarros(), etc. Todos esses atributos sobrecarregam a classe Pessoa. É muito simples cair nesse tipo de problema de coesão, pois: 1- É muito fácil escrever uma mensagem para descobrir quantos cachorros uma pessoa tem, simplesmente fazendo jose.qtdCachorros(); 2- Muitas abordagens de design indicam que qtdCachorros() é um método de Pessoa; 3- Na vida real, se você quiser saber quantos cachorros José tem, você perguntaria a ele. Uma solução para esse problema seria criar uma classe intermediaria, entre Pessoa e Cachorro, que mapaearia a quantidade de cachorros que uma pessoa possui. Problemas de mixed-role cohesion reduzem a reusabilidade de uma classe, fique atento.