O objetivo da herança é justamente este: quando você modela e identifica que duas ou mais classes compartilham mesmas características (atributos) e operações (métodos), você cria uma classe que contemple os elementos comuns e, para cada elemento distinto, você cria subclasses da primeira.
Ou seja, você modela um elemento genérico (mais abrangente) e vai afunilando (especialização).
O grande problema, neste caso, é a questão do java limitar herança múltipla.
Por exemplo:
Você tem dois grandes reinos na natureza, o animal e o vegetal, certo? Podemos dizer que eles são classes.
public class Animal {}
public class Vegetal {}
Um elefante é um animal e uma laranja é um vegetal, fácil.
Também temos que existem seres que se alimentam de plantas, os herbívoros, e temos os que se alimentam de carne, os carnívoros.
Um elefante é herbívoro e um leão é carnívoro. Como você não pode ter herança múltipla, isso não pode ocorrer:
public class Carnivoro {}
public class Leao extends Animal, Carnivoro {} //herança múltipla, java não permite.
O que você faria? Óbvio:
public class Carnivoro extends Animal {}
public class Leao extends Carnivoro {}
Problema resolvido? Não!
Como você faria para representar a classe DioneaMuscipiladora, que é um Vegetal, mas é carnívora? Como você determinou que carnivoro é um animal, você não pode usar carnivoro para vegetais.
Percebe como a herança é limitadora? Ok, entendo que é um cenário hipotético e exagerado, mas, tem muita coisa assim no mundo do desenvolvimento.
Como resolver?
Transformar Carnivoro em uma interface
public interface Carnivoro {}
public class Leao extends Animal implements Carnivoro {}
public class DioneaMuscipiladora extends Vegetal implements Carnivoro {}
Agora sim. Mesmo que você identifique novos adjetivos para Leao ou DioneaMuscipiladora, você pode tratar cada um como sendo interfaces, permitindo que eles implementem isso.
public interface Mamifero {}
public class Leao extends Animal implements Mamifero, Carnivoro {}
Entendeu?
Ah, sim, é óbvio que você pode usar herança, mas, sempre se pergunte se não ficaria melhor com composição ou com implementação.