Publicado em: 09/04/2009 23:18:44

Bruno[color=brown:324a0d8ef8][/color:324a0d8ef8]
_________________
JavaFree.org

Publicado em: 09/04/2009 23:18:44

Não, essa é a unica desvantagem do Java
Falow
_________________
JavaFree.org

Publicado em: 09/04/2009 23:18:44

Apenas o c++ tem essa qualidade.

Publicado em: 09/04/2009 23:18:44

Oi,

voce pode usar o aspectj (http://www.eclipse.org/aspectj/) para simular
Heranca multipla... mas nao eh extamente a mesma coisa, complica um pouco
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 09/04/2009 23:18:44

As interfaces, de certa forma foram criadas para resolver esse problema

Só que você não consegue herdar de duas classes concretas

Eu já caí em vários casos que isso me ajudaria muuuito

[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

Trabalho com c++ a mais tempo do que com java. Herança múltipla trás mais problemas do que benifícios.

Se formos analisar outros os aspectos da poo então, java dá de 10.

Publicado em: 09/04/2009 23:18:44

Java não permite herança múltipla, justamente por gerar alguns problemas, mas permite que você implemente várias Interfaces. Por exemplo:

public class Fuscao extends Carro implements Aviao, Passaro { }

Abraços
_________________
JavaFree.org

Publicado em: 09/04/2009 23:18:44

joao.vanelli:

Não, essa é a unica desvantagem do Java
Falow

Eu não considero isso uma desvantagem, se analisar a bagunça que é quando à utilizamos fica claro que é uma vantagem, além disso não é um recursos essencial...

Publicado em: 09/04/2009 23:18:44

volnei:

joao.vanelli:

Não, essa é a unica desvantagem do Java
Falow

Eu não considero isso uma desvantagem, se analisar a bagunça que é quando à utilizamos fica claro que é uma vantagem, além disso não é um recursos essencial...

Herança múltipla é ... a pior coisa que inventaram no OO...

Java pode fazer algo semelhante com interfaces:
- Uma classe implementando várias interfaces
- Uma interface extendendo várias interfaces

Publicado em: 09/04/2009 23:18:44

jrodrigues:

volnei:

joao.vanelli:

Não, essa é a unica desvantagem do Java
Falow

Eu não considero isso uma desvantagem, se analisar a bagunça que é quando à utilizamos fica claro que é uma vantagem, além disso não é um recursos essencial...

Herança múltipla é ... a pior coisa que inventaram no OO...

Java pode fazer algo semelhante com interfaces:
- Uma classe implementando várias interfaces
- Uma interface extendendo várias interfaces

Assino!

Cya!
_________________
Sugestão de Livros

-- --

Publicado em: 09/04/2009 23:18:44

jrodrigues:

Herança múltipla é ... a pior coisa que inventaram no OO...

Bom, como eu nunca usei herança múltipla, talvez seja falta de conhecimento. Mas ninguém conseguiu me convencer que isso é ruim

Querem tentar ?

[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

vfpamp:

Bom, como eu nunca usei herança múltipla, talvez seja falta de conhecimento. Mas ninguém conseguiu me convencer que isso é ruim

Querem tentar ?

[]s

Que tal vc dizer antes em que casos precisou de herança multipla? Assim a gente pode te convercer aos poucos.

valeuz...
_________________
Marcos Silva Pereira

Publicado em: 09/04/2009 23:18:44

Deixa eu contar a vez em que eu mais precisei disso.

Eu estava testando o Swing, bem no início, nem tinha entrado no JF ainda. Como eu queria fazer uma bela implementação de um sisteminha de cadastro simples, eu queria herdar os componentes padrões do swing para criar os meus e adicionar algumas funcionalidades.

Precisaria criar os seguintes componentes:
- TextEdit para texto extends JTextField
- NumberEdit para número extends JFormattedTextField
- DateEdit para data extends JFormattedTextField
- Memo para textos grandes extends JTextArea
- FixedCombo para combos de domínio fixo extends JComboBox

Todos eles precisariam ter:
- um atributo nome, porque eu iria utilizar para criar Labels para cada um eles.
- um evento acionado quando o componente recebe o foco, que deveria buscar a barra de status do Frame (Outra classe minha) e colocar seu hint como descrição da barra.
- um atributo String de help, formatado em HTML e um evento de teclado, para que quando fosse pressionado a tecla F1 fosse apresentado ao usuário uma tela com essa String
- um atributo modificado, e um evento para alterar esse atributo, que irá armazenar se o componente foi modificado pelo usuário ou não. Isto será útil para aquela tradicional mensagem: "Itens modificados, deseja realmente sair e perder as informações?"

E alguns outros. Bom, para quem não conhece Swing, essa implementação é IGUAL para todos os componentes que eu desejava. Portanto, bastava fazer uma vez e criar as heranças.

Como eu resolvi?

Herdei todos esses componentes fiz uma classe que contém esses atributos e métodos e declarei um atributo no componente para essa classe. Nessa nova classe tive que criar uma função: configure(Component c) que era invocada quando eu criava a mesma para um componente.

Funciona perfeitamente, mas sempre que eu preciso do nome do componente, para exibir mensagens de erro por exemplo, preciso usar: comp.getExtensao().getNome(), ou implementar uma função getNome em todos os componentes que retorna extensao.getNome(). Mesmo assim é código extra.
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

vfpamp:

Deixa eu contar a vez em que eu mais precisei disso.

E em que herança múltipla ia ajudar nisso? Você ia criar uma classe tipo essa?

class Campo extends JTextField, JFormattedTextField, JTextArea, JComboBox {     ... }

Uma solução com interfaces seria: definir uma interface básica e estender cada um dos componentes (JComboBox, JTextField, etc) para implementar essa interface. Depois, criar o componente genérico, que usaria composição (não seria, mas sim conteria) para usar o componente correto, acessando-o através da interface comum.

Pra mim, a solução com interfaces é bem mais limpa, e fácil de manter e estender, não?
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)

Publicado em: 09/04/2009 23:18:44

ronaldtm:

vfpamp:

Deixa eu contar a vez em que eu mais precisei disso.

E em que herança múltipla ia ajudar nisso? Você ia criar uma classe tipo essa?

class Campo extends JTextField, JFormattedTextField, JTextArea, JComboBox {     ... }

Não, não

class NumberEdit extends JFormattedTextField, Extensao { .. }

ronaldtm:

Uma solução com interfaces seria: definir uma interface básica e estender cada um dos componentes (JComboBox, JTextField, etc) para implementar essa interface. Depois, criar o componente genérico, que usaria composição (não seria, mas sim conteria) para usar o componente correto, acessando-o através da interface comum.

Pra mim, a solução com interfaces é bem mais limpa, e fácil de manter e estender, não?

Foi isso que acabei fazendo :D.

[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

vfpamp:

Foi isso que acabei fazendo .

Então, não acha essa solução (com interfaces) melhor?
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)

Publicado em: 09/04/2009 23:18:44

ronaldtm:

vfpamp:

Foi isso que acabei fazendo .

Então, não acha essa solução (com interfaces) melhor?

Siceramente não...

Tive que escrever muita coisa a mais.. duplicar muitas chamadas e a cada componente que eu precise novo, vou ter que implementar tudo again.

PS: Tem bem mais coisa nessa classe de Extensão
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

vfpamp:

Tive que escrever muita coisa a mais.. duplicar muitas chamadas e a cada componente que eu precise novo, vou ter que implementar tudo again.

PS: Tem bem mais coisa nessa classe de Extensão

É, só sabe quem já passou por isso, né

Mas ainda acho que herança múltipla traria mais problemas que vantagens. O que eu acho é que isso ia ser muito mal utilizado, e com o tempo as hierarquias de classe iam ficar uma zona na maioria dos projetos.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)

Publicado em: 09/04/2009 23:18:44

Só prá por mais lenha...

A solução de C++ tbm é meio capenga

Ex:

a)Tenho uma classe Veiculo
b)Aviao é uma especialização de Veiculo
c)Bote é uma especialização de Veiculo
d)Aerobote é uma especializacao de Aviao e Bote (herança múltipla)

Certo?

Errado. Dá erro de compilaçao. Em Aerobote a classe veículo é ambígua...

Ou seja, é uma meleca. Torna o código enrolado e qdo vc mais precisa, tê deixa na mão...

Publicado em: 09/04/2009 23:18:44

beta:

Só prá por mais lenha...

A solução de C++ tbm é meio capenga

Ex:

a)Tenho uma classe Veiculo
b)Aviao é uma especialização de Veiculo
c)Bote é uma especialização de Veiculo
d)Aerobote é uma especializacao de Aviao e Bote (herança múltipla)

Certo?

Errado. Dá erro de compilaçao. Em Aerobote a classe veículo é ambígua...

Ou seja, é uma meleca. Torna o código enrolado e qdo vc mais precisa, tê deixa na mão...

aahhh... agora tem uma razão...

heheh

A implementação tem que funcionar, senão não tem nem graça
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

A bronca é que muita gente usa herança quando quer apenas reusar codigo de maneira facil ou apenas quando quer polimorfismo. E isso é um antipattern. Herança deve ser usada quando vc quer tanto reuso quanto polimorfismo. Acho que, removendo os casos super escabrosos, herança multipla pode ser substituida sem muitas broncas por composição ou uso de interfaces. Se vc quer alterar o comportamento do objeto encapsulado via especialização de algum metodo, use herança simples nele e não na classe que o contem.

valeuz...
_________________
Marcos Silva Pereira

Publicado em: 09/04/2009 23:18:44

Oi

Um cara me falou que podemos solucionar o problema de Herança múltipla usando uma coisa que ele chama de "Delegar". Já procurei no google por:"Herança múltipla" + delegar + java é não encontrei nada.

Já ouviram falar disso?

falou
_________________
JavaFree.org

Publicado em: 09/04/2009 23:18:44

Oi,
delegacao é um padrao bastante simples. O objeto A (GraphNode) contem uma
referencia (variavel do tipo) ao objeto B (Graphic). No objeto A voce implementa
os mesmos metodos que irao chamar os metodos correspondentes do
objeto B. Desta maneira o objeto A praticamente "herda" a funcionalidade
do objeto B.
Por exemplo, tenho duas classes Node e Graphic, e quero uma classe
GraphNode herdando de Node e Graphic:
class Node { public void setName(String newName) { } } class Graphic { public void setX(int x) { } public int getX() { return 0; } } class GraphNode extends Node { private Graphic graphic; public void setX(int x) { graphic.setX(x); } // delegacao public int getX() { return graphic.getX(); } // delegacao }
É claro que tambem poderia usar delegacao para o Node e usar uma
variavel Node em vez do extends....

Aqui Alguns links...
http://en.wikipedia.org/wiki/Delegation_pattern
http://c2.com/cgi/wiki?WhatIsDelegation
http://www.free-definition.com/Delegation-pattern.html
_________________
  Nome real: Carlos F. Heuberger

Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!

"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.

Publicado em: 09/04/2009 23:18:44

beta:

Só prá por mais lenha...

A solução de C++ tbm é meio capenga

Ex:

a)Tenho uma classe Veiculo
b)Aviao é uma especialização de Veiculo
c)Bote é uma especialização de Veiculo
d)Aerobote é uma especializacao de Aviao e Bote (herança múltipla)

Certo?

Errado. Dá erro de compilaçao. Em Aerobote a classe veículo é ambígua...

Ou seja, é uma meleca. Torna o código enrolado e qdo vc mais precisa, tê deixa na mão...

class Veiculo {};
class Aviao: public virtual Veiculo {};
class Bote: public virtual Veiculo {};
class Aerobote: public Aviao, public Bote {};

Funciona

Mas é uma bosta de qualquer forma... se vc não tem acesso ao fonte das classes não dá pra saber se a herança é virtual, se tem herança, etc.
Herança múltipla só gera bagunça.

[]'s
_________________
JavaFree.org

Publicado em: 09/04/2009 23:18:44

Tadeu_Santos:

class Veiculo {};
class Aviao: public virtual Veiculo {};
class Bote: public virtual Veiculo {};
class Aerobote: public Aviao, public Bote {};

Funciona :!:

Mas é uma b*** de qualquer forma... se vc não tem acesso ao fonte das classes não dá pra saber se a herança é virtual, se tem herança, etc.
Herança múltipla só gera bagunça.

[]'s

tem razao... :oops: Implementaçoes vazias funcionam... Mas se vc tiver algum método virtual em veículo (Interface, fazendo um paralelo com Java) dá pau...

Ex:
class Veiculo {    virtual int getClasse() = 0; }; class Aviao: public virtual Veiculo {    int getClasse () {       return 1;    } }; class Bote: public virtual Veiculo {    int getClasse () {       return 2;    } }; class Aerobote: public Aviao, public Bote {};

Publicado em: 09/04/2009 23:18:44

Oi galera,

Estive numa palestra sábado passado, 28/08, ministrada pelo Paulo da Caelum.

Nesta palestra ele abordou a substituição de extensão por composição, e foi muito consistente nas suas colocações e exemplos. Ele tomou como base livros como o do Fowler e do GOF, que aconselham a mesma coisa.

Acredito que no caso de composição teriamos uma solução para o problema.

Caso queiram dar uma olhada na palestra e disponibilizo os slides em:www.paulo.com.br ai é só clicar em Java e escolher a pelestra de 28/08.

[]'s

Sandro
_________________
Sandro Santos Guimarães
SCJP 1.4
Em Jesus somos mais que vencedores
www.lumpa.com.br - O seu site de relacionamento profissional

Publicado em: 09/04/2009 23:18:44

Pela pouco que sei, as interfaces, de certa forma foram criadas para resolver esse problema.

Publicado em: 09/04/2009 23:18:44

Aviao eh Aviao...
Carro eh Carro
Aerobote eh uma terceira coisa, totalmente diferente das duas anteriores, mas q tem as duas funcionalidades... ou seja: "implementa" carro e implementa aviao...

define interface pra "VeiculoTerrestre" e interface pra "VeiculoAereo"

pronto... a sua classe AeroBote fica assim:

class AeroBote extends Veiculo implements VeiculoTerrestre, VeiculoAereo { }

eh absurdo querer usar heranca multipla pra um problema como esse, ou como outro qualquer similar...

e outra, quem nunca usou nao pode dizer q eh ruim, muito menos q eh bom... :P

Publicado em: 09/04/2009 23:18:44

interface em Java eh pra possibilitar polimorfismo, como mostrei ali em cima, e nao heranca multipla no sentido real da coisa (como em C++)...

Java NAO tem e NAO "xunxa"/"faz gambiarra" pra ter heranca multipla... polimorfismo nao eh 100% a mesma coisa q heranca multipla...

Publicado em: 09/04/2009 23:18:44

Ok, vamos para a prática

Interface Veículo {     ....    public void andar(int x);    public void parar();    public void virar(int angulo);     .... } Carro extends veículo { ... } Navio extends veículo { ... } Anfíbio extends Carro, Navio { ... }

Imagina você implementando tudo o que um carro tem. Mover rodas, eixos, aceleração, freios, luzes, cambio, ignição, etc. Vamos imaginar, que a implementação disso custe umas 15 mil linhas de código java. Para navio a mesma coisa: Leme, mastros, aceleração, rotação, freio, etc. Mais umas 15 mil linhas.

Anfíbio, nada mais é do que um carro que pode andar na água. Portanto vai necessitar das duas implementações.
tp assim:

public void andar(int x) {    if (anfibioMode)        Anfibio.super.andar(x);    else        Carro.super.andar(x); } public void parar() {     super.parar(); // Chama o método dos dois Carro e Navio. } public void virar(int angulo) {     super.virar(angulo); // Chama o método dos dois Carro e Navio. }
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

a ideia eh justamente vc nao ter aquele if/else no metodo andar...

um metodo nunca pode fazer condicionalmente duas coisas... :P isso eh boa pratica de arquitetura de software... nao tenho detalhes, mas jah ouvi isso... :P

quem vai dizer pro objeto Anfibio q ele tah na agua? quer dizer entao q um objeto Lago deve ter dois metodos? um pra objeto Navio e outro pra objeto Anfibio?

class Lago {   void receber(Navio) {}   void receber(Anfibio) {     anfibio.setAnfibioMode(true);   }

eh isso q vc quer? pq pra mim nao parece nada elegante...

Publicado em: 09/04/2009 23:18:44

o correto eh fazer como passei no reply acima...

desta forma a classe Anfibio seria:

class Anfibio extends Veiculo implements Carro, Navio {   void navegar(int km, int nos) {}   void dirigir(int km, int speed) {} } class Lago {   void receber(Navio n) {     n.navegar(...);   } } class Rodovia {   void receber(Carro c) {     c.dirigir(...);   } }


esse eh o certo... :P

Publicado em: 09/04/2009 23:18:44

Um carro anfíbio funciona de duas maneiras:
- Ou você diz que ele está em modo Navio ( setAnfibioMode(boolean mode) )
- Ou um sensor indica que há água em determinada parte da carcaça, portanto um evento que ativa o modo navio.

Se fizer isso fica assim:

class Lago {   void receber(Navio n) {      n.setDentroDaÁgua(true) // Este método ativa o modo navio do anfíbio. Método sobrescrito.   } }

[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

miojo:

esse eh o certo...

Pode até ser o certo, mas dai terá que se implementar em Anfíbio TUDO o que está na classe carro e tudo o que está na classe navio. Produtivodade? Re-utilização?

[]s
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

Mais uma coisinha: Anfíbio É um carro e É um navio e não TEM um carro e TEM um navio
_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

nao tudo... mas pelo menos um dos dois... afinal, um veiculo anfibio eh de preferencia um carro, mas tem suporte a andar na agua...

entao vc faz ele herdar de Carro, mas implementar Navio...

pois, pra ele poder navegar, eh preciso recolher rodas, fechar cano de descarga, etc... coisas q carro tem e navio nao... ou seja, a classe anfibio precisa saber q EH um anfibio... e q pra poder navegar, existem algumas pré-condicoes...

e ateh mesmo pra dirigir... pois se ele saiu da agua, eh preciso habilitar novamente as rodas... e por ae vai....

ou seja: mesmo q vc tivesse heranca multipla, precisaria sobrescrever/acrescentar codigo... e seu codigo nao ficaria elegante, principalmente pq forcaria outras classes q nao tem nada a ver, a saber declaradamente q existe um anfibio no meio deles: ter dois metodos no Lago por ex.

Publicado em: 09/04/2009 23:18:44

miojo:

nao tudo... mas pelo menos um dos dois... afinal, um veiculo anfibio eh de preferencia um carro, mas tem suporte a andar na agua...

entao vc faz ele herdar de Carro, mas implementar Navio...

Se fosse um navio a vela tu tava fodido para implementar tudo denovo

Quote:

pois, pra ele poder navegar, eh preciso recolher rodas, fechar cano de descarga, etc... coisas q carro tem e navio nao... ou seja, a classe anfibio precisa saber q EH um anfibio... e q pra poder navegar, existem algumas pré-condicoes...

e ateh mesmo pra dirigir... pois se ele saiu da agua, eh preciso habilitar novamente as rodas... e por ae vai....

Quote:

ou seja: mesmo q vc tivesse heranca multipla, precisaria sobrescrever/acrescentar codigo...

Quote:

e seu codigo nao ficaria elegante,

Quote:

principalmente pq forcaria outras classes q nao tem nada a ver, a saber declaradamente q existe um anfibio no meio deles: ter dois metodos no Lago por ex.

Publicado em: 09/04/2009 23:18:44

Pq não poder fazer isso?


_________________
Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona

Publicado em: 09/04/2009 23:18:44

vfpamp:

Um carro anfíbio funciona de duas maneiras:
- Ou você diz que ele está em modo Navio ( setAnfibioMode(boolean mode) )
- Ou um sensor indica que há água em determinada parte da carcaça, portanto um evento que ativa o modo navio.

nao... vc nao precisa ter q dizer pra um navio q ele entrou na agua... afinal, navio soh funciona dentro da agua...

se a classe Lago chama o metodo navegar de um navio, o objeto navio espera q vai estar dentro da agua... entao se o objeto eh uma instancia de anfibio, internamente eh q ele mesmo vai ativar seu modo anfibio... entendeu?

algo como:

private void setAnfibioMode(boolean); public void navegar(...) {   setAnfibioMode(true);   ... }

e antes de postar os argumentos, nao se limite ao exemplo de carro/navio/anfibio, pois eh logico q nesse caso eh possivel encontrar contra-argumentos simples, afinal, o exemplo eh meio besta... tente aplicar as ideias em outros exemplos... sei lah, usa a imaginacao ae vai...

o lance do "O CARA" a meu ver eh resultado de: pessima modelagem e preguiça de codificacao...

e nao tem utilidade nenhuma... ou tem? :P

Publicado em: 09/04/2009 23:18:44

corrigindo: no lance do OCara pode ateh ter uma utilidade sim, mas lembre-se q vc tah dando possibilidade do programador cometer bizarrices no modelo OO liberando a heranca multipla...

um poco de conceito OO: O primeiro objetivo da heranca nao eh reaproveitar codigo, e sim especializar codigo!

Dúvida Simples
http://javafree.uol.com.br/topic-8874-Duvida-Simples.html

inserindo numa especializacao PAPEL no hibernate...
http://javafree.uol.com.br/topic-851485-inserindo-numa-especializacao-PAPEL-no-hibernate.html

Utilizar métodos de mais de uma classe no mesmo programa???
http://javafree.uol.com.br/topic-862601-Utilizar-metodos-de-mais-de-uma-classe-no-mesmo-programa.html

palavra chave 'native'
http://javafree.uol.com.br/topic-851172-palavra-chave-'native'.html

Como implementar composição em java
http://javafree.uol.com.br/topic-851566-Como-implementar-composicao-em-java.html

Herança Multipla
http://javafree.uol.com.br/topic-889192-Heranca-Multipla.html

Herança múltipla
http://javafree.uol.com.br/topic-867855-Heranca-multipla.html

Exemplos práticos de Herança Múltipla
http://javafree.uol.com.br/topic-859163-Exemplos-praticos-de-Heranca-Multipla.html

Java é uma linguagem pura ???
http://javafree.uol.com.br/topic-854084-Java-e-uma-linguagem-pura.html