Mesmo que esse assunto pareca ja explorado de todas as formas ainda ha certas situacoes que relutamos (pelos menos eu) em usar a heranca ao inves da composicao.Invejando descaradamente o conto de cada dia do Phillip . Vou contar de uma experiencia que tive. O exemplo classico e o controlador CRUD (seja seu servelet, managed bean, action form... ) que contem os metodos para uso geral e generico e alguns ganchos. Vou dar um exemplo bem simples de um Managed Bean CRUD.public class ManagedBeanCRUD [E,ID]{private E instancia;public E getInstancia(){return instancia;}public Void setInstancia(E entidade){this.instancia = entidade;}public String salvar(){preSalvar();servicoCrud.salvar(getInstancia);return "navegacaoListar";}public void preSalvar(){}}E apartir desse MB crio os meus outros CRUDS simples, exemplo telefone:public class TelefoneMB extends ManagedBeanCRUD [Telefone, Integer] {@Overridepublic void preSalvar(){System.out.println("Oi esse e gancho ...");}}Otimo, houve reuso por meio da heranca mas logo veio as seguintes perguntas: porque nao transformou os metodos preXXX em metodos abstratos? Porque dai eu teria que obrigar o usuario a implementar sempre mesmo quando nao fosse necessario. porque nao usou composicao ao inves da heranca? Porque minha visao (xhtml) ja esta toda padronizada.[c:campoentrada binding="#{mb.instancia.numero}"/][c:botao binding="#{mb.salvar}"/]Note que o metodo salvar nao existe (ao menos no fonte) na classe TelefoneMB ele e acessado por heranca. A primeira tentativa foi substituir a heranca por composicao por meio de delegacao, minha classe TelefoneMB ficaria mais ou menos assim:public class TelefoneMB{private ManagedBeanCRUD[Telefone, Integer] delegate;public String salvar(){ return delegate.salvar();}// + do mesmo}Mas sera que nao pode ser melhorado?!Claro que sim ate agora consegui chegar num patamar assim: os metodos ganchos se transformam no padrao decorator e a heranca se torna composicao por delegacao mas de um modo diferente, fiz o MangedBeanCRUD ser um atributo de leitura :public class TelefoneMB{private ManagedBeanCRUD[Telefone, Integer] crud;public TelefoneMB(){ crud.addEventoPreSalvar(new Evento(){ public void executar(){ System.out.println("antes de salvar..."); } });}public ManagedBeanCRUD getCrud(){ return crud;}}E na view (jsf, xhtml ...) nao terei muita mudanca sera uma navegacao a mais na #EL #{telefonemb.crud.salvar} terei que adicionar o crud antes do padrao CRUD de ser.Com isso tenho um managed bean livre de mas praticas, melhorei o sistema de eventos e mais um plus nao terei problemas futuros com proxies do JDK ou GLIB2! Mais camadas e indirecoes sempre foi o caminho conforme post sobre abstracoes pra todo lado.Todo comentario sempre e e sera bem-vindo!ps: so pra deixar claro nao sou contra o uso da heranca, ha casos que voce pode usar heranca para compor suas entidades e outros n usos. O unico cuidado que deve ter e pensar, pensar, pensar e pensar para decidir se e heranca ou nao. No padrao JPA voce pode anotar suas entidades pelos metodos (getters) ou pelos atributos, e um ou exclusivo ou vocE anota tudo pelos atributos ou pelos getters. O relato que segue e sobre um codigo que funcionou muito bem por muito tempo mas que na ultima sexta feira (28/05/2010) me deu muita dor de cabeca.Devido a limitacao do JSF (1.X) quanto a populacao de combos (o usuario do framework e obrigado a passar uma lista/matriz de SelectItem), eu criei um codigo para que dado uma lista de objetos, o nome do atributo a ser mostrado