Déjà cette forme pose problème : tu déclares une variable qui existe déjà (Coiffeur), ce qui n'est pas possible.
Comme ça, oui :
DAO<Coiffeur> daoCoiffeur = new CoiffeurDAO().create(Coiffeur);
Si tu choisis cette forme, c'est que create retourne du "DAO<Coiffeur>". C'est intéressant pour pouvoir enchaîner :
1
2
3
4
| new CoiffeurDAO().create(coiffeur1)
.create(coiffeur2)
.create(machinChose)
.create(biduleChoutte); |
Cela peut avoir un côté pratique, mais d'un autre côté ça l'est moins, parce que par exemple, si tu as une collection, tu sera de toute manière obligé de faire :
1
2
3
4
5
|
DAO<Coiffeur> daoCoiffeur = new CoiffeurDAO();
for(Coiffeur coiffeur : coiffeurCollection) {
daoCoiffeur.create(coiffeur);
} |
si tu veux éviter de créer autant d'instance de daoCoiffeur que de coiffeurs.
Mais on peut régler ça en ajoutant des méthodes qui prennent en paramètre une collection, un tableau (ou un varargs), un itérateur, un stream...
En revanche, cette forme est problématique pour les méthodes qui retournent déjà une donnée (d'un autre type), comme le cas de la méthode qu'on a vu avant, qui retourne l'id de la prestation créée (ou -1) si elle n'existe pas. Mais tu peux orienter la classe pour que les méthodes exposées (publiques) soient toutes de cette forme, et que les méthodes qui retournent quelque chose de spécial soient internes (protected, voire private), et appelées forcément à l'intérieure de méthodes exposées.
Par exemple (de principe, je n'ai pas regardé si ça correspondait à ton modèle) :
1
2
3
4
5
6
7
8
| public CoiffeurDAO create(Coiffeur coiffeur, Prestation prestation) {
int idPrestation = create(prestation);
if ( idPrestation==-1 ) {
throw new SQLException("Impossible de créer le coiffeur : prestation non créé");
}
create(coiffeur, idPresation);
return this;
} |
avec create(Prestation prestation) et create(Coiffeur coiffeur, int idPrestation) privées.
Autre solution : intégrer dans tes classes l'id, ce qui te permettra de les utiliser dans tous les contextes du CRUD.
1
2
3
4
5
6
7
8
9
10
11
12
13
| public class Coiffeur {
private int id;
private String nom;
Coiffeur(String nom) {
this(-1, nom);
}
Coiffeur(int id, String nom) {
this.id=id;
this.nom=nom;
}
/**...**/
} |
La méthode create(Prestation) deviendra :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| public CoiffeurDAO create(Prestations prestations) throws SQLException {
try(Connection cnx = getConnexion()) {
/** .... **/
try (ResultSet generatedKeys = pst.getGeneratedKeys()) {
if (generatedKeys.next()) {
prestations.setId(generatedKeys.getInt(1));
}
else {
throw new SQLException("Erreur lors de la création de prestations, pas d'identifiant obtenu.");
}
}
return this;
} |
Ce qui pourra te permettre d'écrire des trucs dans le genre:
1
2
3
|
new CoiffeurDAO().create(prestation) // créé un nouvel enregistrement avec les données de prestation, récupère un nouvel id de prestations
.createWith(coiffeur, prestation); // créé un nouvel enregistrement de coiffeur, en utilisant l'id de prestation s'il y en a un, ou la créer s'il y en a pas |
avec
1
2
3
4
5
6
7
8
9
10
11
| public CoiffeurDAO create(Prestations prestation) {
/**....**/
}
public CoiffeurDAO create(Coiffeur coiffeur, Prestations prestations) {
if( prestations.getId()==-1 ) {
create(prestations);
}
coiffeur.setPrestation(prestations);
create(coiffeur);
return this;
} |
etc.
Après rien n'empêche d'avoir des méthodes des deux formes. (des méthodes qui retournent du Dao<Coiffeur> et d'autres qui retournent du Coiffeur, du Prestation, etc...
La forme que tu décris est utilisée en général pour les builders. Des classes qui créer des instances d'autres classes qui ont plein de paramètres optionnels, pour éviter d'avoir 50 méthodes avec toutes les combinaisons, et qui permet d'écrire des trucs du genre :
1
2
3
4
5
6
7
8
9
10
| Style style1 = new StyleBuilder().setFontName("Arial")
.setFontSize(25)
.setUnderline(true)
.setColor(Color.RED)
.setWeight(Weight.BOLD)
.create();
Style style2 = new StyleBuilder().setFontName("Arial")
.setWeight(940)
.setOutlined(true)
.create(); |
Un DAO se présente plus comme une façade (un regroupement de services diverses (CRUD) sous une même classe) avec une partie fabrique éventuellement (avec des méthode du genre Coiffeur createCoiffeur(String nom)). J'éviterais cette forme personnellement (bien que j'en sois assez friand habituellement).
Projet d'application en Java : Interaction Java / BDD en JDBC
Répondre avec citation
Partager