Se vc for usar a mesma lógica para todos os DAOs. Então crie uma classe Abstrata com os métodos definidos save, update e find definidos e outros. Depois vc pode extender essa classe.
Ouuu criar a interface e ficar definindo a mesma lógica de save, update e find em cada classe que implementa-la.
M
mendigosujo
Legal
Mas não posso extender? Não dá no mesmo?
victorwss
Olha, minha experiência:
Já fiz uma classe DAO genérica e ficou bem legal (usando pesadamente generics e reflection). Ela é independete de SGBD, embora só funcione para DAOs baseados em SGBDs relacionais.
Desta DAO genérica, subclasses herdam dela. Mas… Se eu fosse fazer isso atualmente, eu usaria composição. Não há nada nesse DAO genérico que eu fiz que justifique a herança a não ser a relação ClienteDAO É-UM DAO. Se eu usasse composição teria ficado bem mais simples (ClienteDAO delega para DAO genérico).
Há alguns problemas nesse DAO genérico relativos a possibilidade de DAOs que não trabalhem com SGBDs relacioanis (DAOs que trabalham em arquivos, ou que enviam requisições remotas via RMI, webservices ou qualquer coisa assim). Para resolver isso, bastou criar aquele esquema de interface para DAO, com uma implementação que trabalha diretamente no SGBD (via DAO genérico), e outras implementações que trabalham como bem entenderem.
EDIT: Tá demorando para o pcalcado aparecer. Ele já escreveu toneladas sobre esse assunto analisando dezenas de abordagens diferentes. Você pode procurar por aí os textos dele.
M
mendigosujo
O que é composição?
victorwss
TEM-UM
Exemplo: Carro TEM-UM motor. Ou seja:
public class Carro {
private Motor motor;
// Todo o resto da classe.
}