Bom dia,
Gostaria de um esclarecimento sobre herança.
O conceito de herança sempre deve seguir quando tal objeto É UM ?
Por exemplo:
Funcionario É UMA Pessoa ?
Eu posso usar herança simplesmente para herdar atributos ?
Por exemplo:
Carro TEM AtributosCarro (Peso, Cor, Comprimento, Altura etc.)
PortaCarro TEM AtributosCarro (Peso, Cor, Comprimento, Altura etc.)
RodaCarro TEM AtributosCarro (Peso, Cor, Comprimento, Altura etc.)
Isto é válido ?
Desta maneira ai não é uma boa prática. Pelos menos é o que parece a 1º vista.
Explique melhor o que vc deseja fazer ou este exemplo é só didático?
Sim e não.
Por que sim? Porque funciona se fizer dessa maneira.
Por que não? Porque é uma péssima prática, a ideia de herança é realmente herdar TUDO o que a classe pai tem. Atributos e comportamentos.
a herança deve fazer sentido. como Cachorro herdando de Animal.
pesquise sobre Interfaces, e também sobre Composição
Há uma grade diferença entre herdar e ser composto por.
Por exemplo, uma casa é composta por tijolos, embora ambos objetos possuam características comuns, uma casa não é um tijolo.
Casa e tijolo são objetos, logo, herdam características comuns a todos os objetos, como peso, tamanho, quantidade de lados, etc.
Casa é um tipo de abrigo. De abrigo, herda todos os comportamentos e todas as características. Um tijolo é um material de construção. De material de construção, herda todas as características, bem como, de outros tipos de objetos dos quais herda, quando o universo-problema é outro.
Por exemplo, um cachorro é um animal, quando o foco do universo-problema vê como necessária essa relação.
Mas cachorro também é um amigo, quando o foco é a relação de amizade.
Ou seja, vai depender do escopo de onde você quer colocar carro, porta e farol.
Porém, pela abordagem que usou, já começa errado. Porta, carro e farol TEM UM atributosCarro (peso, cor, etc).
Você é um filho, possui todas as características e operações comuns a todos os filhos. Mas, se ainda não é pai, não TEM UM filho, assim sendo, não pode dizer que herda de pai. Entendeu?
[quote=InicianteJavaHenrique]Desta maneira ai não é uma boa prática. Pelos menos é o que parece a 1º vista.
Explique melhor o que vc deseja fazer ou este exemplo é só didático?[/quote]
Somente didático.
[quote=drsmachado]Há uma grade diferença entre herdar e ser composto por.
Por exemplo, uma casa é composta por tijolos, embora ambos objetos possuam características comuns, uma casa não é um tijolo.
Casa e tijolo são objetos, logo, herdam características comuns a todos os objetos, como peso, tamanho, quantidade de lados, etc.
Casa é um tipo de abrigo. De abrigo, herda todos os comportamentos e todas as características. Um tijolo é um material de construção. De material de construção, herda todas as características, bem como, de outros tipos de objetos dos quais herda, quando o universo-problema é outro.
Por exemplo, um cachorro é um animal, quando o foco do universo-problema vê como necessária essa relação.
Mas cachorro também é um amigo, quando o foco é a relação de amizade.
Ou seja, vai depender do escopo de onde você quer colocar carro, porta e farol.
Porém, pela abordagem que usou, já começa errado. Porta, carro e farol TEM UM atributosCarro (peso, cor, etc).
Você é um filho, possui todas as características e operações comuns a todos os filhos. Mas, se ainda não é pai, não TEM UM filho, assim sendo, não pode dizer que herda de pai. Entendeu?[/quote]
Já esclareceu…
A minha dúvida é, estou começando a projetar um sistema e gostaria de começar certo! Usando herança acredito que com o crescimento dele terei prováveis problemas, por que o conceito de herança talvez não se encaixaria muito bem no futuro.
No meu sistema terei vários objetos que tem atributos em comum como peso, comprimento, tipo, modelo que poderia ser herdados de uma classe pai mas não se enquadrariam dentro do conceito “É UM”. Somente usaria para centralizar os atributos.
Outro caminho seria o uso de interface e composição… mas usando interface não poderei usar variaveis comente metodos???
é… uma interface define contratos que a classe implementadora terá que cumprir… portanto são métodos… quando você implementa uma interface, está dizendo que a classe vai fazer algo.
Agora em relação aos atributos, acho que composição resolve.
Se você tem mais de um objeto que possui os mesmos atributos, por que não cria uma classe que possa servir como um atributo único para ambas? (Ahn?)
A
public class A{
private int peso;
private int altura;
private Cor cor;
//getters e setters
}B
public class B{
private A a;
private Outro outro;
//getters e setters
}C
public class C{
private A a;
private MaisUm maisUm;
//getters e setters
}Isso se chama composição.
B tem um A e C tem um A também.
m
A minha dúvida é, estou começando a projetar um sistema e gostaria de começar certo!
Já que vai começar evite heranças , programe orientado a interfaces e crie composições …
[quote=Aleksandro]A minha dúvida é, estou começando a projetar um sistema e gostaria de começar certo!
Já que vai começar evite heranças , programe orientado a interfaces e crie composições … [/quote]
É o que eu li nos livros. Mas quando usar heranças, quais os tipos de sistemas ficariam com uma boa arquitetura usando herança ? sistemas pequenos e simples ?
[quote=drsmachado]Se você tem mais de um objeto que possui os mesmos atributos, por que não cria uma classe que possa servir como um atributo único para ambas? (Ahn?)
A
public class A{
private int peso;
private int altura;
private Cor cor;
//getters e setters
}B
public class B{
private A a;
private Outro outro;
//getters e setters
}C
public class C{
private A a;
private MaisUm maisUm;
//getters e setters
}Isso se chama composição.
B tem um A e C tem um A também.[/quote]
Opa drsmachado,
A minha ficha não tinha caído sobre essa sistemática. Assim resolve o meu problema completamente e agora ficou bem mais claro e óbvio pra mim que p uso de composição e interface torna o sistema mais dinâmico.
[quote=starke][quote=Aleksandro]A minha dúvida é, estou começando a projetar um sistema e gostaria de começar certo!
Já que vai começar evite heranças , programe orientado a interfaces e crie composições … [/quote]
É o que eu li nos livros. Mas quando usar heranças, quais os tipos de sistemas ficariam com uma boa arquitetura usando herança ? sistemas pequenos e simples ?[/quote]
Na verdade o conceito de herança é antigo e muito mal usado , o próprio criador do java o sr. gosling diz que ao invés de subclasse, basta usar as interfaces puras e porque ele diz isto :
Na verdade como já disseram as classes filhas precisam conhecer muito bem o funcionamento destas e as vezes até o código da classe mãe … portanto herança quebra o encapsulamento …
mais detalhes … segue o link … http://www.artima.com/intv/gosling3P.html
Independente do tamanho do sistema o ideal é evitar …e seja feliz … na site da caelum há alguns tópicos sobre o assunto e são muito interessante …boa sorte …
O uso de herança só é recomendado quando e onde não cabe composição, ou seja, muito raramente.
A herança é um recurso da OO (não apenas do java) que visa criar um objeto novo, que pode ou não ter atributos e métodos próprios, a partir de um outro objeto.
Blz pessoal. Ficou claro pra mim agora, não estava conseguindo enxergar as melhoria usando a composição.
Muito obrigado a todos.
Boa tarde a todos.
A meu ver a herança só deve ser usada quando você terá várias classes com atributos e ou métodos comuns entre elas, e não tão somente duas classes (super e sub classe) com seus atributos e ou métodos comuns.
Assim como o nosso amigo Drsmachado já definiu muito bem, os conceitos de herança e composição, o uso da herança é recomendável, por exemplo, quando você quer padronizar não somente a assinatura do método, mas também a sua implementação, e o exemplo melhor para isto seria você implementar um método incluir() a várias classes, onde este método utiliza os mesmos atributos que estão encapsulados na super classe, e a mesma implementação, o que te permite um código mais enxuto nas demais classes que a herdam.
Tal qual já foi dito também o principal uso da interface, que tem a função de estabelecer o uso de métodos comuns entre várias classes, porém única desvantagens das interfaces, é que você estabelece os métodos comuns sem estabelecer um padrão as suas implementações, fazendo todos os seus métodos serem abstratos, a passo que a herança você pode padronizar comportamentos comuns com suas implementações comuns a várias classes, junto com métodos abstratos, fazendo da classe uma classe abstrata.
Contudo, o uso de interfaces também tem as suas grandes vantagens que é de estabelecer os métodos comuns que variam suas implementações entre as classes, além é claro, de permitir uma classe implementar várias interfaces, recurso este que veio substituir a herança múltipla.
Um abraço.
Ok, agora surgiu outra dúvida. Usando a herança poderei definir a classe super como abstract e usando composição não poderei fazer isso, como posso garantir que a minha classe de atributos não vá ser instanciada desnecessariamente ?
Essa tua pergunta não tem resposta fácil e vai depender do estilo de cada pessoa.
Mas uma arquitetura que as pessoas consideram como padrão da coisa bem-feita é a java.util.Collection. Dá uma olhada nela.
Heranca geralmente é boa prática quando vc alinha uma classe abstrata com uma interface.
Ex:
Map -> AbstractMap -> HashMap
Map -> AbstractMap - LinkedHashMap
etc.
Raramente no mundo real vc vai precisar de uma hierarquia longa. Ao invés disso tenta partir para um conjunto de interfaces.
E dizem os puritanos que é melhor favorecer composicao, principalmente quando há uma interface envolvida. Se não há uma interface aí se vc partir para composicão o polimorfismo se perde. Aí é ruim.
Agora vai entender porque Josha Bloch herdou LinkedHashMap de HashMap ao invés de fazer composicão? Ou porque o java.util.Properties herda de Hashtable?
Isso vai do estilo / gosto de cada um. O cara que é apaixonado por testes unitários geralmente foge de heranca criando bonecas russas. Cada um com o seu gosto.