É um e Tem um

Fiz uma prova e me deparei com o seguinte codigo…não conseguir enteder o motivo que eles definiram tal resposta como a certa…se alguem soubesse e pudesse me esplicar eu agradeceria…

class Bridge{
Road read;
}

class Road{
String name;
Bridge myBridge;
}

ela perguntava…
Que tipo de relacionamento está representado?
a)Nenhum
b)uma relação “is a”(é uma)
c)uma relação “has a”(tem um)
d)ambas as relaçoes estao representada"is a" e “has a”

eu achei que a resposta certa seria a “C”,mas eles deram como certa a ‘D’…

pelo que sei…“is a” tem a ver com herança"extends" ou interface “implements”…enquanto “has a” tem a ver com “variavel de instancia”…
nao entendi realmente o motivo que eles colocaram a d) como certa…se alguem tiver uma resposta mais clara…por favor postem ai…agradeco

Bom, se a gente fosse levar a pergunta ao pé da letra, eu acho que a (A) seria a correta.
No código, não há nada que represente uma Herança entre as Classes, ou seja, o Extends.

Agora, do meu ponto de vista para um possível acoplamento entre essas duas classes, Uma Ponte pode ter uma Estrada, mas a Estrada não pode ter uma ponte. No máximo, um trecho da estrada seria uma ponte.

O correto então, no meu ponto de vista, é não existir acoplamento, e sim, Implementação, porque um trecho da estrada pode ser uma ponte.

Uma relação ‘é um’ é representada por uma especialização, ou seja, herança.
Uma relação ‘tem um’ é representada por uma composição ou agregação (que são representados do mesmo jeito em java, com um atributo).

Nos 2 casos acima o que existe é a relação ‘tem um’, embora não esteja adequada no caso da ponte (mas o caso aqui é analisar o que está descrito, e não o que é correto).

[]'s

[quote=wariows]Uma relação ‘é um’ é representada por uma especialização, ou seja, herança.
Uma relação ‘tem um’ é representada por uma composição ou agregação (que são representados do mesmo jeito em java, com um atributo).

Nos 2 casos acima o que existe é a relação ‘tem um’, embora não esteja adequada no caso da ponte (mas o caso aqui é analisar o que está descrito, e não o que é correto).

[]'s[/quote]

Só um adendo: Em java É-UM não é só através de herança, implementando uma interface também.

Andre,
Eu também iria na C.
Onde você fez essa prova?

[quote=rafaelglauber][quote=wariows]Uma relação ‘é um’ é representada por uma especialização, ou seja, herança.
Uma relação ‘tem um’ é representada por uma composição ou agregação (que são representados do mesmo jeito em java, com um atributo).

Nos 2 casos acima o que existe é a relação ‘tem um’, embora não esteja adequada no caso da ponte (mas o caso aqui é analisar o que está descrito, e não o que é correto).

[]'s[/quote]

Só um adendo: Em java É-UM não é só através de herança, implementando uma interface também.[/quote]

Interface é uma coisa inventada para o java para manobrar herança múltipla e não entrar no problema do diamante. Eu consideraria a mesma coisa que herdar de uma classe abstrata, com a ressalva de que ela não tem descrição de estado, somente de comportamentos.

Não é uma questão de você achar ou não, se tiver uma questão deste teor numa certificação java (a pergunta foi feita num forum java e o próprio autor da pergunta sugere o que eu falei) você tem que levar interface em consideração sim, e interface não se herda, se implementa.

Não é uma questão de você achar ou não, se tiver uma questão deste teor numa certificação java (a pergunta foi feita num forum java e o próprio autor da pergunta sugere o que eu falei) você tem que levar interface em consideração sim, e interface não se herda, se implementa.[/quote]

Olha em que seção do fórum o tópico está e você verá que certificação não tem nada a ver com isso… E eu não falei que se herda de interface, eu falei que consideraria a mesma coisa que herdar de uma classe abstrata…

Wariows, interface não é um conceito inventado pelo Java. Na verdade, ele existe até em C++ e a linguagem até tem um suporte especial para isso. Mas ele não é tão explícito quanto em Java. Em C++, você define uma interface criando uma classe abstrata que contenha apenas métodos virtuais puros e nenhum atributo (tal como é a interface do Java). Esse tipo de classe não sofre do problema do diamante da morte, que você mencionou.

Aliás, é importante que fique claro que o conceito “interface” não tem nada a ver com linguagem nenhuma. Ele representa um contrato em duas classes, ou seja, a relação que a classe A é implementada em termos da interface B. Portanto, também não representa uma relação de herança.

Tanto que na UML, a simbologia de ambas é radicalmente diferente. Uma classe abstrata é desenhada como uma classe normal com o nome em itálico. Uma interface é desenhada como uma bolinha. A relação das classes é a “extends” e a da interface é a “realization”. Isso porque os conceitos são diferentes, embora os mecanismos para usar esses conceitos, em muitos casos, são similares.

No caso específico dessa questão, a resposta certa é a letra que você marcou.
Na letra D, seria realmente necessário herança, o que não ocorre nessa relação.

[quote=ViniGodoy]Wariows, interface não é um conceito inventado pelo Java. Na verdade, ele existe até em C++ e a linguagem até tem um suporte especial para isso. Mas ele não é tão explícito quanto em Java. Em C++, você define uma interface criando uma classe abstrata que contenha apenas métodos virtuais puros e nenhum atributo (tal como é a interface do Java). Esse tipo de classe não sofre do problema do diamante da morte, que você mencionou.

Aliás, é importante que fique claro que o conceito “interface” não tem nada a ver com linguagem nenhuma. Ele representa um contrato em duas classes, ou seja, a relação que a classe A é implementada em termos da interface B. Portanto, também não representa uma relação de herança.

Tanto que na UML, a simbologia de ambas é radicalmente diferente. Uma classe abstrata é desenhada como uma classe normal com o nome em itálico. Uma interface é desenhada como uma bolinha. A relação das classes é a “extends” e a da interface é a “realization”. Isso porque os conceitos são diferentes, embora os mecanismos para usar esses conceitos, em muitos casos, são similares.

No caso específico dessa questão, a resposta certa é a letra que você marcou.
Na letra D, seria realmente necessário herança, o que não ocorre nessa relação.
[/quote]

Conheco os métodos virtuais, eu estou falando do termo interface, tanto é que sempre que falamos de interface citamos “interface de classe” e “interface java”… A questão é que aqui é um tópico de java básico, apenas tentei ser o mais simples possível para explicar o conceito.

Oi,

[quote]
Conheco os métodos virtuais, eu estou falando do termo interface, tanto é que sempre que falamos de interface citamos “interface de classe” e “interface java”… A questão é que aqui é um tópico de java básico, apenas tentei ser o mais simples possível para explicar o conceito. [/quote]

neste caso você deixaria de ser didático e passaria a ensinar conceitos errados, mesmo sendo java básico o próprio autor da mensagem mostra conhecimento de interfaces e classes, tanto que ele só tá querendo confirmar ou não se o gabarito não está errado ou se comeu alguma mosca.

É o que eu estava explicando:

  1. Interface não tem nada a ver com herança ou classe abstrata;
  2. O conceito de interface também existe em C++ e é diferente do de herança múltipla;
  3. Eu quis explicar a diferença entre o conceito de interface e os mecanismos que as linguagens usam para implementa-lo.

[quote=rafaelglauber]Oi,

[quote]
Conheco os métodos virtuais, eu estou falando do termo interface, tanto é que sempre que falamos de interface citamos “interface de classe” e “interface java”… A questão é que aqui é um tópico de java básico, apenas tentei ser o mais simples possível para explicar o conceito. [/quote]

neste caso você deixaria de ser didático e passaria a ensinar conceitos errados, mesmo sendo java básico o próprio autor da mensagem mostra conhecimento de interfaces e classes, tanto que ele só tá querendo confirmar ou não se o gabarito não está errado ou se comeu alguma mosca.[/quote]

A parte de simplicidade fica para o primeiro post, quando te falei da classe abstrata estava fazendo uma comparação e não explicando um conceito… btw, sim, está certo dizer que realização também é uma relação ‘é um’ (se era o que vc queria ler… :stuck_out_tongue: )

:wink:

É o que eu estava explicando:

  1. Interface não tem nada a ver com herança ou classe abstrata;
  2. O conceito de interface também existe em C++ e é diferente do de herança múltipla;
  3. Eu quis explicar a diferença entre o conceito de interface e os mecanismos que as linguagens usam para implementa-lo.[/quote]

E eu to tentando explicar que eu não estava falando do conceito e sim do termo u_u

deixa pra lá :stuck_out_tongue_winking_eye:

E ai galera…obrigado pelas opinioes…postei essa pergunta no forum de java basico pq é uma pergunta de nivel basico.e nao conseguir achar a logica da instuiçao ter posto a letra D como a certa,pq…a relaçao de “é um” tem que ter “extends” ou “implements” na questao…rsss…como nao achei nada que indicasse uma hernça ou implementaçao…fiquei me perguntando onde que eles acharam essa relaçao “é um”…apesar de tambem nao ter logica a relaçao ‘tem um’ entre a ponte e “tem um” entre a estrada…pq ,como postaram:uma estrada tem uma ponte mas uma ponte nao tem estrada…nao considerei essa logico…pq na pergunta esta explicito que uma ponte tem uma estrada,assim como uma estrada tem uma ponte…rsss…
e respondendo a pergunta onde eu fiz a prova:: Foi pra programador do exercito…Sargento programador…

e galera…so lembrando:: Interface é apenas um contrato 100%abstrato,onde as suas variaveis sao Constantes:“public static final” e os seus metodos sao abstratos:“public abstract”…logo a primeira classe concreta que quiser implementa-la…ou seja…contratar seus servicos…vao ter que usar seus metodos…e nao alterar o valor de suas variaveis…isso se for variaveis primitivas…ou nao alterar a referencia dos seus objetos…isso se a variavel é uma referencia ao objeto…
enquanto que a classe abstrata pode ter ou nao metodos nao abstrato…mas terar pelo menos um metodo abstrato…e a primeira classe concreta que extende-las…vao ter a obrigaçao de usar seus metodos abstratos…blz…flow…galera