Discussion :

[concombre]

Bonjour,

J'ai lu la description du pattern DAO sur la page de Sun et une question me trotte dans la tete.

Si j'ai bien compris, leur recommandation est la suivante:
- Si vous n'utilisez qu'un seul type de BDD, il faut utiliser le pattern Factory Method
- Si vous utilisez différents types de BDD, il faut mettre en place le pattern Abstract Factory

Dans le cas du pattern Factory Method, si l'on sait que l'on ne va utiliser qu'un seul type de BDD, je ne saisi pas l'interêt du niveau d'indirection supplémentaire ajouté par CloudscapeDAOFactory.

Pourquoi ne pas rendre DAOFactory concrete et la charger d'instancier directement les classes DAO ? (la classe CloudscapeCustomerDAO deviendrait simplement CustomerDAO dans ce cas)

Exemple:
CustomerDAO customerDAO = DAOFactory.getCustomerDAO();
customerDAO.insertCustomer(customer);

S'il s'agit d'un mécanisme permettant l'éventuel ajout d'un autre type de BDD par la suite, autant implémenter directement une fabrique abstraite.

Voilà, si quelqu'un à une opinion sur le sujet je serai tres interessé

[ego]

Outre le fait qu'une bonne pratique générale est la programmation par "interface" (= on définit toujours le contrat d'une classe au travers d'une interface et ensuite on propose une implémentation), l'idée est ici qu'en proposant une interface, tu vas pouvoir proposer une implémentation qui sera un "bouchon", les anglais parlent de mocked object. Ainsi, tu pourras tester ton appli sans avoir la "vraie" implémentation tant que celle-ci n'est pas encore développée.
Ce principe est abondamment utilisé dans le framework Spring. Que je te conseille de regarder si tu t'intéresses aux DAO.

[concombre]

Merci pour ta réponse ego