Perso, je pense qu'aucun paradigme n'est parfait, et qu'ils ont tous un intérêt.
Les langages inspirés du tout objet se plantent royalement pour moi… D'ailleurs, ils font maintenant un peu de générique…
Pour cette histoire de sérialisation, moi je vois comment boost::serialization à fait (enfin, ce qu'il nous faut faire pour s'en servir) et je trouve le résultat plutôt pas mal.
Chaque classe sérialisable à une fonction template serialize() et est amie avec un des classes de boost. A partir de là, suffit de coller dans un fichier les implémentations template et basta (il proposent d'autres méthodes, mais c'est celle que j'ai préférée)
D'une part, ces implémentations, étant template, n'empêcheront pas de compiler/linker/exécuter en cas d'absence, et d'autre part on peut les regrouper toutes dans un seul fichier, potentiellement dans un autre binaire.
Le meilleur, c'est qu'il suffit de faire une classe serialisatrice pour que toutes les classes s'adaptent automatiquement.
Ca rejoint l'idée que ce n'est pas la classe elle-même qui doit savoir comment se sérialiser, mais elle doit savoir quoi sérialiser, et les passer à celle qui saura comment.
Certes, il y a plus de classes. Mais chaque classe ne doit être responsable que d'elle-même, selon les pattern GRASP.
Ces pattern ont effectivement le problème d'avoir plus de classes, mais elles sont plus petites, et donc bien plus maintenables et réutilisables. Tandis que tout mettre dans une seule classe, c'est comme tout faire dans la même fonction: un erreur qui empêche de connaître les méthodes responsables de la gestion d'une ressource, et qui par la même augmente la difficulté de réparer les bugs.
[^] # Re: POO
Posté par freem . En réponse au journal Du code propre, c'est quoi ?. Évalué à 3.
Perso, je pense qu'aucun paradigme n'est parfait, et qu'ils ont tous un intérêt.
Les langages inspirés du tout objet se plantent royalement pour moi… D'ailleurs, ils font maintenant un peu de générique…
Pour cette histoire de sérialisation, moi je vois comment boost::serialization à fait (enfin, ce qu'il nous faut faire pour s'en servir) et je trouve le résultat plutôt pas mal.
Chaque classe sérialisable à une fonction template serialize() et est amie avec un des classes de boost. A partir de là, suffit de coller dans un fichier les implémentations template et basta (il proposent d'autres méthodes, mais c'est celle que j'ai préférée)
D'une part, ces implémentations, étant template, n'empêcheront pas de compiler/linker/exécuter en cas d'absence, et d'autre part on peut les regrouper toutes dans un seul fichier, potentiellement dans un autre binaire.
Le meilleur, c'est qu'il suffit de faire une classe serialisatrice pour que toutes les classes s'adaptent automatiquement.
Ca rejoint l'idée que ce n'est pas la classe elle-même qui doit savoir comment se sérialiser, mais elle doit savoir quoi sérialiser, et les passer à celle qui saura comment.
Certes, il y a plus de classes. Mais chaque classe ne doit être responsable que d'elle-même, selon les pattern GRASP.
Ces pattern ont effectivement le problème d'avoir plus de classes, mais elles sont plus petites, et donc bien plus maintenables et réutilisables. Tandis que tout mettre dans une seule classe, c'est comme tout faire dans la même fonction: un erreur qui empêche de connaître les méthodes responsables de la gestion d'une ressource, et qui par la même augmente la difficulté de réparer les bugs.