O que seria um design apropriado de uma relação é-um? Porque pra mim uma classe estender outra já seria o suficiente para caracterizar tal relacionamento apropriadamente. Sempre que respondo questões sobre esse assunto eu logo procuro pela palavra chave extends afim de verificar um relacionamento do tipo é-um. Essa dúvida surgiu ao me deparar com a questão abaixo que apresenta somente as alternativas A e D como corretas. Será que apropriado está relacionado a herança feita com classes que não sejam da API Java? Se alguém puder tirar essa dúvida eu agradeço.
Given:
public class Team extends java.util.LinkedList {
public void addPlayer(Player p) {
add(p);
}
public void compete(Team opponent) { /* more code here */ }
}
class Player { /* more code here */ }Which two are true? (Choose two.)
A. This code will compile.
B. This code demonstrates proper design of an is-a relationship.
C. This code demonstrates proper design of a has-a relationship.
D. A Java programmer using the Team class could remove Player
objects from a Team object.
Um Team (time) pode ter uma (has a) lista de jogadores, mas não é só uma lista de jogadores (is a). Ele normalmente teria mais coisas (um técnico etc.)
Portanto a alternativa B não está correta.
Lembre-se: normalmente, nesse tipo de questões, você precisa ser menos bitolado e não cair matando na relação “extends”.
A alternativa C também não está correta, porque você não vê a relação “has a” sendo implementada. Você a veria sendo implementada se a definição da classe fosse:
class Team {
List <Player> players = new ArrayList<Player>();
}
É claro que existe, mas se você pensar direito, um Time não é só uma List<Player>; e é por isso que normalmente, quando a classe-base é uma estrutura de dados básica do Java, o relacionamento “is-a” (pelo menos nesses exercícios) não é um “proper design”.
Sim. Agora ficou mais claro. Como não sou bom nenhum pouco em inglês a letra D para mim estaria errada e como por falta de entendimento na tradução marcaria a letra B. Mas agora ficou mais claro.
[quote=thingol]É claro que existe, mas se você pensar direito, um Time não é só uma List<Player>; e é por isso que normalmente, quando a classe-base é uma estrutura de dados básica do Java, o relacionamento “is-a” (pelo menos nesses exercícios) não é um “proper design”.
[/quote]O que vc quis dizer com “um Time não é só uma List<Player>”? Pq qualquer classe q herde de outra não será só a classe estendida, no mínimo era será um Object tb. Ou se trata de uma questão subjetiva, onde eu tenho q pensar além do código apresentado? Não entendi essa colocação, se puder esclarecer ficarei grato.
[quote=javadev]Será que apropriado está relacionado a herança feita com classes que não sejam da API Java?[/quote]Posso usar isso como regra?
O problema é que a questão nao especifica quais classes esta tomando com referencia para estabelecer os relacionamentos…
mas provavelmente ele se refere a Team e Player…
assim…Team não tem um player…pois não declara nenhum atributo deste tipo…
e Team não é um Player pois ela não herda dessa classe.
Existe um relacionamento é-um…
Um Team é um LinkedList…
independente de qualquer contexto…isso não é subjetivo…
se vc criar uma variavel do tipo LinkedList e atribui-la um objeto Team…compilará sem problemas.
