Discussion :

[celes]

Bonjour,

Une question difficile à exprimer mais qui me pose problème sur mon projet actuel :

Je souhaite réaliser un système de version au sein de mon projet en fonction de dates. Je m'explique :

Admettons qu'une méthode, située n'importe où au sein du projet ne soit plus valable à un moment donné et remplacée par une autre. Cependant, cette méthode serait toujours valable le jour où on souhaiterait l'utiliser en se reportant dans le passé.

Un cas concret (et simplifié) :
On calcule le salaire d'une personne dans une entreprise à une certaine date. Un jour, on se rends compte qu'une loi à changé et qu'a partir d'une certaine date, il va falloir prendre en compte d'autres paramètres mais que le jour où on voudra recalculer le salaire de cette personne, les anciens paramètres devront toujours exister (par exemple si on se rends compte que ce salarié à été mal calculé, il faudra le recalculer mais avec les anciennes lois).

Dans mon cas, le projet existe déjà depuis un certain temps. Je trouve personnellement que ce projet a été mal réalisé mais il est tellement gros que je ne peux me permettre de tout recommencer.

Est-ce que quelqu'un connait une solution pour me permettre de créer par exemple, un contrôleur universel au sein du projet pour superviser les méthodes en fonction d'une date de mise en service de cette méthode et d'une date d'expiration ?

Biensur, il existerai un moyen simple, en écrivant en dur dans chaque méthode, un if tout bête en testant la date, mais le projet est tellement gros, que ça demanderai un travail énorme et un risque d'erreur omniprésent, chose que je ne peux me permettre. Donc, évitez cette proposition, merci !)

Je suis désolée que ma question soit si complexe mais le projet sur lequel je suis est déjà bien compliqué à la base et en plus, c'est du C# qui a été réalisé quasiment en intégralité en programmation structurée (sans concept objet)

[Pol63]

juste par curiosité tu bosses où ?

un design pattern factory devrait aller
c'est à dire au lieu d'instancier directement une classe, on appelle un constructeur de classe qui lui retourne une instance, le factory peut alors testeer la date, et après y a le choix entre une interface et plusieurs classes ou une classe overridable de partout et un héritage

enfin de toute facon, si tu es sur un programme codé n'importe comment, la seule solution est de tout réécrire, parce que si vous etes pas sur des concepts objets, c'est pas évident à modifier

le but dans le développement c'est de penser avant de coder, ou alors de coder de manière assez ouverte pour anticiper les modifications ...

[smyley]

un design pattern factory devrait aller
c'est à dire au lieu d'instancier directement une classe, on appelle un constructeur de classe qui lui retourne une instance, le factory peut alors testeer la date, et après y a le choix entre une interface et plusieurs classes ou une classe overridable de partout et un héritage

+1
J'aurai même exporté tout ça vers des dlls séparés et les aurai utilisé sous forme de plugin. Comme cela elles sont suffisamment indépendante pour ne pas avoir besoin d'une connaissance globale du projet pour corriger une erreur par exemple (ça se limiterai à l'étude d'un code d'une centaine de ligne à tout casser, ce qui doit être moins que la taille du programme) et leur modification n'entrainera pas la recompilation de tout le programme.
Sinon c'est sur que cette méthode prendra du temps, mais après tu sera tranquilles pour un moment.

[celes]

je ne peux pas vraiment dire où je travaille... Je ne voudrais pas m'attirer des problèmes.

Disons que je travaille en tant qu'analyste dans une division programmation d'une très grande entreprise.
Je me trouve au sein d'une équipe de bras cassés, sur un projet de création d'un logiciel de calcul de salaire pour les nombreux employés de l'entreprise.

Le projet date de 4 ans environ, je suis arrivée en novembre dernier. Le projet ne contient aucun diagrammes UML, aucune étude. Il a été commencé et presque entièrement codé par un débutant qui n'a absolument pas commenté son code.

Je commence à assimiler la plupart des classes (90% en static. La seule partie correctement codée à été faite par une société extérieure qui leur à donné un coup de main pendant une courte période. De cette façon, le moteur du projet est de qualité.) et méthodes mais c'est assez dur, je l'avoue ^^ D'autant plus que je n'ai pas non plus un passé de 10 ans de programmation derrière moi (un bras cassé remplace un bras cassé).
La seule différence, c'est que j'ai une vraie motivation et que je ne veux pas continuer à mettre des pansements sur un projet qui finira par devenir complètement imbuvable.. Je cherche des solutions dans cette ambiance stressante pour tout le monde (retards, bugs à corriger, nécessité de resultat pour les chefs qui n'ont jamais fait de programmation de leur vie, etc...) et profite justement d'être là depuis peu (on ne me demande pas grand chose pour l'instant)... Biensur, si je leur explique qu'il faut tout recommencer, vu l'argent dépensé (ça se mesure en milliers de k€), je doute qu'on me fasse un large sourire.


Pour faire simple, le projet véhicule une énorme variable, un genre de contexte qui passe dans la plupart des méthodes et qui est traité de façon à donner au final quelque chose qui permet de faire une fiche de salaire et payer l'employé.
Lorsque je suis arrivée, j'ai vu que le plus gros problème sera justement lorsqu'il faudra faire des versions des méthodes en fonction des dates puisque les lois évoluent...

Je n'ai jamais utilisé de design pattern factory mais l'idée de parait bonne. Je vais le comprendre et apprendre à m'en servir.

Merci pour ce conseil précieux.

[Pol63]

bonne chance alors ^^