25-03-2008, 12:44 AM
En réalité je travaille toujours avec des objets qui représentent mes tables (des "Data Access Objects") et ces fonctions sont donc des méthodes statiques des classes correspondantes.
Dans Symfony, ce serait une méthode de la classe FlightPeer
La couche d'abstraction SQL, elle, est une librairie tierce.
Note :
La séparation en fonctions atomiques comme ça peut faire peur au début, on trouve ça chiant à débugger parce qu'il faut sauter de fichier en fichier pour trouver la source, et on se dit que ça craint parce qu'il y a un milliard de fichiers à charger et que ça plombe les ressources.
En réalité on finit par utiliser un vrai éditeur (genre Eclipse) qui permet de simplifier ces "sauts" (ctrl+click sur nom d'une fonction et hop on arrive à sa déclaration), et le problème du nombre de fichiers est un faux problème car entre 3 petits fichiers et un gros, le disque ne travaille pas bien plus que ce soit dans un cas ou dans l'autre...
Mais surtout à la fin on se rend compte combien une fonction de 10 lignes est plus simple à débugger qu'une fonction de 50 lignes
C'est simple chez moi mon éditeur m'affiche 25 lignes de code sur une page, si je n'arrive pas à afficher toute ma fonction sur une page alors je sais qu'il y a de grandes chances qu'il faille refactoriser tout ça 
(pas toujours hein, juste très souvent), c'est à dire éclater ma grosse fonction en de petites fonctions "atomiques" (ne fais qu'une chose, mais fais-la bien, ça vous rappelle quelque chose au niveau philosophie de développement ?).
Dans Symfony, ce serait une méthode de la classe FlightPeer
La couche d'abstraction SQL, elle, est une librairie tierce.
Note :
La séparation en fonctions atomiques comme ça peut faire peur au début, on trouve ça chiant à débugger parce qu'il faut sauter de fichier en fichier pour trouver la source, et on se dit que ça craint parce qu'il y a un milliard de fichiers à charger et que ça plombe les ressources.
En réalité on finit par utiliser un vrai éditeur (genre Eclipse) qui permet de simplifier ces "sauts" (ctrl+click sur nom d'une fonction et hop on arrive à sa déclaration), et le problème du nombre de fichiers est un faux problème car entre 3 petits fichiers et un gros, le disque ne travaille pas bien plus que ce soit dans un cas ou dans l'autre...
Mais surtout à la fin on se rend compte combien une fonction de 10 lignes est plus simple à débugger qu'une fonction de 50 lignes
C'est simple chez moi mon éditeur m'affiche 25 lignes de code sur une page, si je n'arrive pas à afficher toute ma fonction sur une page alors je sais qu'il y a de grandes chances qu'il faille refactoriser tout ça (pas toujours hein, juste très souvent), c'est à dire éclater ma grosse fonction en de petites fonctions "atomiques" (ne fais qu'une chose, mais fais-la bien, ça vous rappelle quelque chose au niveau philosophie de développement ?).
Ressources [PHP][MySQL][![[Image: fav.png]](http://prototypejs.org/images/fav.png)
prototype.js]
prototype.js]