Arquivo Discussoes de Programacao e Tecnologia 
Ao escrever meus programinhas utilizando OO, sempre tenho a tendência — ou vício — de sempre implementar relações de pertinência (ou agregação, se preferirem) entre classes, sem avaliar se uma relação de herança seria mais apropriada.
Que dicas vocês poderiam me dar a respeito? Como eu poderia “julgar” se, na minha aplicação, uma relação de herança entre classes é — ou não — mais conveniente que uma relação de pertinência?
Rapaz, cada caso é um caso diferente, tudo vai sempre depender do contexo, não dá pra dizer que vai ser sempre herança nem vai ser sempre agregação.
Todas as vezes que eu tive que fazer uma escolha dessa, eu juntei o bom senso e as perguntinhas mágicas “é um?” e “tem um?” para resolver a questão.
As duas abordagem são válidas, depende muito do contexto. Mas, em minha opinião, é muito mais fácil estragar um domínio de objetos fazendo mal uso de herança do que usando composição.
Depois de analisar o meu código (e o contexto no qual ele se aplica), decidi optar pela herança, mas agora surgiu outra dúvida.
Digamos que eu tenha duas classes, ClasseA e ClasseB. Na minha cabeça, um objeto ClasseB é um caso particular de um objeto ClasseA e, conseqüentemente, a minha tendência seria fazer ClasseB herdar de ClasseA.
Por outro lado, no que diz respeito ao código, um objeto ClasseB contém menos informação, isto é, menos métodos e atributos, que um objeto ClasseA. Levando isso em conta, talvez fosse melhor fazer ClasseA herdar de ClasseB.
O que eu posso fazer? Quem deve herdar de quem?
PS: Atualmente, no meu código, guardo em ClasseA um atributo que é um objeto ClasseB (relação de agregação). Um método de ClasseA retorna um outro objeto ClasseA, com o mesmo atributo ClasseB do objeto original e com todos os demais atributos nulos.
Se vc tem classes que possuem métodos em comum mas que no mundo real não tem relação de herança crie uma interface e faça com que suas classes implemente-a.
Ola,
Num otimo porem defasado livro, Arthur Riel descreve heuristicas para um projeto OO. Um resumo das heuristicas eh encontrado aqui.
Destas, as que se aplicam ao caso:
Note que mesmo Riel deixa bem claro que essas heuristicas sao guias, nao leis. Nao eh preciso seguir 100% delas (e algumas eu realmene nao concordo).
Herança de implementaçao eh util mesmo quando classes nao tem muito em comum (e isso eh um ponto favoravel a herança multipla). Interfaces definem contratos e comortamento esperado, mas muitas vezes voce precisa simplesmente reaproveitar codigo. Nesse caso geralmente um refactoring com Extract SuperClass ajuda.