Tout d'abord, merci à tous pour vos réponses et principalement à eulbobo pour cette réponse très complète !
Je te l'avoue, cela me fait beaucoup de notions d'un coup, moi qui ai l'habitude de programmer en utilisant simplement des classes, sans classes abstraites, interfaces, ou même héritage ![:|](https://www.developpez.net/forums/images/smilies/icon_neutral.gif)
Là tu te dis "oui, mais une fois que je récupère mon ResultSet, il faut bien que je puisse avoir un moyen de le transformer en un résultat qui ait un sens".
Du coup, plusieurs possibilités :
- Faire en sorte que ta classe Requete soit abstraite, déclarer une méthode abstraite de type protected qui s'appellera par exemple "convertResultSet", et ensuite, pour chaque utilisation de requête dont tu as besoin, créer une implémentation de Requete (RequeteFacture par exemple) qui ne fera qu'implémenter la conversion de ResultSet
Je comprends ta solution mais j'avais codé mon application de manière à ce qu'elle soit le plus modulable possible et que j'ai juste à effectuer pour une requête select par exemple
ResultSet resultat = req.requeteSelect("Ma requête aussi complexe que je le veux");
et ensuite récupérer les informations comme je le souhaitais.
Pour la suite je comprends ce que tu proposes mais quand tu dis
Ici, tu disposes d'une classe fille dont le rôle est d'interroger la base de données pour un domaine précis et de renvoyer des résultats. Et le fait de renvoyer des intitulés de lignes est propre au traitement d'une facture, ça n'a rien de générique (donc rien à faire dans une classe de niveau plus élevé)
Avantage : le code SQL est regroupé dans les classes qui gèrent les accès et les requêtes à la base de données. Du coup, les interfaces n'ont plus à devoir manipuler des objets du niveau de la base de données (baisse du niveau de couplage)
là, je me pose une question. Toutes les requêtes que nous seront amenés à faire au sein de notre application devront donc avoir une méthode prévue pour la réaliser ? Pour ce type d'application plutôt légère ça va, mais si l'application est plus lourde et offre beaucoup plus de possibilités (je pense à plusieurs possibilités de filtrage par exemple ?), n'y aurait-il pas trop de méthodes à créer ? Car comme tu le dis en citant mon code je fais
ResultSet resultat = req.requeteSelect("select intitule from ligue");
et je pensais que cela était bien plus propre que de créer une méthode pour chaque requête que je pourrai avoir à faire souvent.
Dernière amélioration possible ici : utiliser le concept de composition d'objets avec des classes qu'on va appeler Transformer. Dont le but sera de transformer un ResultSet précis dans un résultat.
Je t'avoue qu'à partir d'ici, je suis largué. Je comprends le concept, l'utilité que ça peut avoir, mais je trouve tout de même ça très abstrait. Je n'ai d'ailleurs jamais vu ou abordé cette notion de Transformer, c'est donc une découverte totale pour moi que j'ai du mal à assimiler, j'irai donc chercher quelques exemples sur internet pour mieux comprendre.
Pour ce qui est des erreurs, dis toi que les exceptions sont là pour ça : quand tu as un problème technique, elles remontent automatiquement jusqu'en haut pour faire sortir du programme... Sauf si tu les interceptes (catch(Exception)) pour pouvoir les traiter.[...]Ce que tu dois faire, c'est le plus haut possible dans ton application, catcher l'exception selon le bon type, et ensuite afficher l'erreur qui ira bien...
C'est vrai que je n'ai pas non plus tendance à faire remonter mes erreurs, dès que je vois une erreur, je la catch et je n'utilise jamais de "Throws". Je n'ai pas appris cette notion de "faire remonter les erreurs" même si je sais qu'elle existe, je me contente simplement de la traiter au niveau ou elle se déclenche car je n'ai jamais été sensibilisé à l'utilité de faire remonter les erreurs.
com.mysql.jdbc.MysqlDataTruncation : utiliser ce genre d'erreur pour vérifier un format de date, c'est super moche ! Une exception, comme son nom l'indique, c'est une exception au bon fonctionnement de l'application, c'est un problème non prévisible. Tout ce qui est prévisible doit être géré. Sinon, tu fais ce qu'on appelle une gestion par exception, et crois moi, ce n'est pas une bonne chose (tu risques de perdre des informations ou masquer des problèmes)
La encore, c'est vrai, même coup que pour les clefs primaires. J'ai eu une exception une fois et j'ai cherché comment la gérer, j'ai trouvé cette solution et je ne me suis pas dit que ça pouvait être une mauvaise manière de répondre à ce problème, merci pour la remarque.
Pour ce qui est de la persistance des données, je connais (très brièvement) Hibernate, mais vu que nous avions eu un ou deux cours sur JDBC je suis resté sur l'utilisation de cette méthode.
De plus, comme le dit eulbobo, ma priorité est d'acquérir de bonnes habitudes pour développer en Java et utiliser au mieux les différentes possibilités offertes par le langage en comprenant déjà par exemple comment éviter les redondances ou comment bien inclure des interfaces ou des classes abstraites de manière efficace et justifiée.
Partager