Acoplamento fraco x Herança

26/03/14 Acoplamento fraco x Herana

www.devmedia.com.br/acoplamento-fraco-x-heranca/3714 1/11

Gostei (6) (1)

Buscar

post favoritocomentrios

Acoplamento fraco x Herana

Acoplamento fraco um dos principais requisitos para seconstruir software orientado a objetos (OO) de qualidade...

Introduo

Acoplamento fraco um dos principais requisitos para se construir software orientado aobjetos (OO) de qualidade. O acoplamento fraco mede o quanto uma classe, depende de, ouest relacionada a, outra classe ou subsistema. A capacidade de uma classe em herdar o

0 3Curtir1

LOGIN



comportamento de outra(s) uma das principais caractersticas do paradigma OO. Aprincipal vantagem poder criar novas classes quase de graa, aproveitando o cdigo deoutra. Esse artigo discute esses dois conceitos e mostra porque a herana, em geral, ajudaa comprometer o acoplamento fraco.

Acoplamento fraco

Uma classe com acoplamento forte depende muito (em geral sem necessidade) de outras.Isso pode conduzir aos seguintes problemas [Larman]:

classes difceis de aproveitar tendo em vista que sempre que esta forutilizada todas as outras das quais ela depende devem estar presentes;

alteraes nas classes relacionadas podem forar mudanas locais e

so difceis de compreender isoladamente.

Formas comuns de acoplamento ocorrem atravs de: variveis de instncia, variveislocais a mtodos ou de seus argumentos, chamada de servios em outra classe, uma classederiva direta ou indiretamente de outra ou uma classe implementa uma determinadainterface. Resumindo, sempre que uma classe referencia um outro tipo em qualquer umadas circunstncias acima est ocorrendo acoplamento. Considere o cdigo:

public class X

{

private ClasseConcretaY var1;

void M1(ClasseConcretaW var2 ) { }



}

Existem dois pontos principais de acoplamento, na varivel de instncia var1, que do tipoClasseConcretaY, e no argumento var2, que do tipo ClasseConcretaW. Nestas duas partesdo cdigo a classe X referencia outras duas classes concretas. Isso significa que, sempreque esta classe for utilizada, as outras duas devero estar disponveis no espao de nomesdo programa. No caso de Java, o(s) pacote(s) onde estas se encontram dever(o) estar noclasspath.

Mas, referenciar outras classes sempre causa problemas de acoplamento? A resposta ,depende! Referenciar classes estveis e disseminadas raramente um problema. Porexemplo, utilizar o pacote java.util num programa em Java dificilmente causar problemasfuturos de acoplamento, uma vez que qualquer ambiente de execuo Java contm essabiblioteca. O problema est em classes instveis, pouco conhecidas, ou seja, nas classesque so criadas para atender os problemas especficos dos projetos.

Como diminuir o acoplamento?

Uma regra geral para diminuir o acoplamento programar para uma interface e no parauma implementao [Gamma]. No exemplo acima isso significa substituir as declaraesdas classes concretas por declaraes de interfaces. Fazendo isso desacopla-se o cdigo deuma implementao especfica, tornando-o dependente apenas de uma interface. Essa no a soluo definitiva, um bom projeto com boas atribuies de responsabilidades crucial,porm ajuda muito. mais fcil compreender isoladamente uma classe que referenciaapenas interfaces e mais [Gamma]:

os clientes (usurios da classe) permanecem sem conhecimento dos tiposespecficos dos objetos que eles usam, contanto que os objetos tenhamaderncia interface que os clientes esperam,os clientes permanecem sem conhecimento das classes que implementamestes objetos; eles somente tm conhecimento das classes abstratas quedefinem a interface.



Herana

A herana a principal caracterstica de distino entre um sistema de programaoorientado a objeto e outros sistemas de programao. As classes so inseridas em umahierarquia de especializaes de tal forma que uma classe mais especializada (subclasse)herda todas as propriedades da classe mais geral (superclasse) a qual subordinada nahierarquia.

O principal benefcio da herana o reaproveitamento de cdigo. A herana permite aoprogramador criar uma nova classe programando somente as diferenas existentes nasubclasse em relao superclasse. Isto se adeqa bem a forma como compreendemos omundo real, no qual conseguimos identificar naturalmente estas relaes.

A reutilizao por meio de subclasses dito reutilizao de caixa branca, pois usualmenteexpe o interior das classes ancestrais para as subclasses. A herana definidaestaticamente em tempo de compilao e simples de utilizar, uma vez que suportadadiretamente pela linguagem de programao.

Acoplamento fraco x Herana

A deciso de derivao a partir de uma superclasse precisa ser cuidadosamenteconsiderada, uma vez que ela uma forma muito forte de acoplamento [Larman]. Asclasses ancestrais freqentemente definem pelo menos parte da representao fsica dassuas subclasses. A implementao de uma subclasse, desta forma, torna-se to amarrada implementao da sua classe me que qualquer mudana na implementao desta foraruma mudana naquela. Vejamos uma situao onde isso verdadeiro. Considere oesquema de herana abaixo:

abstract public class X

{

private final int MAX = 100;



public int CalculaMaximo(int i)

{

return i * MAX;

}

public int UsaMaximo(int i)

{

int maximo = CalculaMaximo(i);

//faz alguma coisa de til com maximo

}

}

public class Y extends X

{

public void UsaMetodoDaClasseX()

{

.



int aux = UsaMaximo(10);

}

}

At aqui tudo bem! Agora considere a seguinte modificao na classe X:

abstract public class X

{

private final int MAX = 100;

public int CalculaMaximo(int i)

{

return (int) i * (MAX /100); // Aproxima o resultado com cast

}

public int UsaMaximo(int i) { }

}

Essa alterao na maneira como o mximo est sendo calculado pode gerar efeitos



colaterais na classe Y. A aproximao para inteiro pode funcionar para alguns mtodos queusam a CalculaMaximo() mas provocar resultados errneos na UsaMetodoDaClasseX().Assim, para que a classe Y continue funcionando, esta precisaria ser adaptada novarealidade. Problemas podem ocorrer tambm quando estruturas de dados visveis nasclasses derivadas so alteradas. Um array bidimensional transformado para vetor oumesmo um tipo int modificado para float certamente acarretar problemas.

Este exemplo simples ajuda a mostrar como uma alterao na implementao de ummtodo numa classe base pode provocar anomalias nas suas classes derivadas.Observe que no ocorreu uma alterao de interface, o que necessariamente (enotoriamente) implica em alteraes nas classes clientes. por isso que a herana, emparticular, revela um alto acoplamento. Alm das hierarquias de classes criadas estaremsuscetveis s mudanas de interface, esto suscetveis tambm s alteraes nasimplementaes dos mtodos.

Quando uma subclasse redefine algumas, mas no todas as operaes, ela tambm podeafetar as operaes que herda, assumindo-se que elas chamam as operaes redefinidas[Gamma]. Isso gera um efeito semelhante ao apresentado acima, porm no sentido oposto,onde alteraes nas classes mais especializadas podem gerar problemas nas classes base.Se a classe Y tivesse sobrescrito o mtodo CalculaMaximo(), o problema com aaproximao poderia ocorrer no mtodo UsaMaximo() da classe X.

Como evitar a herana?

Uma outra forma de reaproveitar funcionalidade atravs da composio de objetos.Novas funcionalidades so obtidas compondo objetos para obter funcionalidades maiscomplexas. Uma das vantagens desta abordagem a flexibilidade em poder selecionar emtempo de execuo qual objeto ser usado na composio (contanto que este respeite ainterface definida). No exemplo anterior, se a classe Y tivesse uma referencia para umoutro objeto com a funcionalidade definida em X, quando este fosse alterado restaria a elaainda a possibilidade de utilizar uma verso antiga e seu funcionamento no estarianecessariamente comprometido.



Gostei (6) (1)

O que voc achou deste post?

Concluso

Evitar herana e privilegiar a composio em geral uma boa prtica em projetosorientados a objetos. Favorecer a composio de objetos em relao herana ajuda amanter cada classe encapsulada e focalizada em uma nica tarefa. Suas classes ehierarquias de classes se mantero pequenas e mais tratveis [Gamma]. Alm disso, vimoscomo e porqu a utilizao da herana resulta num alto acoplamento e os problemas queisso pode acarretar.

Bibliografia

[Gamma] Gamma, E; Helm, R; Johnson, R; Vlissides, J. Padres de Projeto Solues Reutilizveis de Software Orientado a Objetos, Bookman, 2000.

[Larman] Larman, C. Utilizando UML e Padres, Bookman, 2004.

ChristianCleberMasdevalBraz

ChristianCleberMasdevalBraz([email protected])bacharelemCinciadaComputaopelaUFMS.Em2004concluiuomestrado,tambmnaquelainstituio,nareadeintelignciaartificialeproblemascombinatoriaisdifceis[...]



Seja o primeiro a comentar

Publicidade

ServiosInclua um comentrioAdicionar aos FavoritosMarcar como lido/assistidoIncluir anotao pessoal

+Java

undefined



Mais postsArtigo

Integrando o JADE a IDE NetBeans

Pocket Video

Como integrar o VNC com Java e C#

Pocket Video

Pacotes em Java - Verificando a compatibilidade

Artigo

Restaurando Segurana no Tomcat com BadInputFilter

Artigo

Data Join com Hadoop MapReduce

Video aula

Removendo a Venda - Curso JBoss: Introduo e AplicaoMVC completa - Aula 140

Video aula

Editando a Venda - Curso JBoss: Introduo e Aplicao MVCcompleta - Aula 139

Video aula

Criando conversores e gravando a Venda - Curso JBoss:Introduo e Aplicao MVC completa - Aula 138



Artigo

Java BigDecimal: Trabalhando com mais preciso

Artigo

JavaServer Faces 2.2: aumento de produtividade

Listar mais contedo

Anuncie | Loja | Publique | Assine | Faleconosco

HospedagemwebporPorta80WebHosting

TodososDireitosReservadosaWeb03

DevMedia

21.331pessoascurtiramDevMedia.

PluginsocialdoFacebook

Curtir

Acoplamento fraco x Herança

Documents

Transcript of Acoplamento fraco x Herança