Discussion :

[Lharuun]

Bonjour a tous,

Je suis actuellement entrain de me poser une question existentielle sur une façon de procéder proprement pour répondre au problème suivant :

J'ai codé une dll utilitaire en C# me facilitant la tache pour tout un tas de chose.
Celle ci commence à dater et se trouve être utilisée dans la quasi totalité de mes projets depuis 5 ans.
J'y ais (presque) toujours apporté un soin particulier quand a la conception et à l'étude de l'API afin de ne pas me retrouver avec des problème incompatibilité entre versions de DLL et version des Soft
L'idée étant de pouvoir utiliser la dernier version de cette DLL quelle que soit cette ayant été utilisée pour la compilation initiale.

Mais voila, j'y ait presque fait toujours attention, et je me retrouve aujourd'hui avec le problème suivant :

J'ai une classe Abstraite A possédant une méthode abstraite M1 qui possède le prototype suivant :
Cette classe est ensuite hérité par des classes spécialisées.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

abstract void M1(string p1);

Et malheur à moi, je ne sais pas pourquoi je n'avais pas prévu et pourtant c’était plus que prévisible que cette méthode doive retourner un Boolean, et ce même si je ne l'ai jamais utilisée jusqu’à aujourd'hui.
Mais voila, aujourd'hui j'ais besoin de ce retour et mon problème est le suivant :

Trouver la solution la plus élégante pour que disposer de cette méthode avec retour sans que l'utilisation de cette DLL avec des projets plus ancien ne nécessite de recompilation. Sachant que si je modifie simplement le type de retour la méthode ne sera plus du tout utilisable avec toutes ces anciennes applications.

Pour l'instant la solution que j’entrevoie naïvement serait de laisser cette méthode dans l'état et d'en créer une nouvelle qui pourrait avoir la tête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

abstract Boolean M1_Avec_Retour(string p1);

Obligeant ainsi tous les appels avec un retour vers cette méthode.
ou de re-compiler tous les projets avec la nouvelle DLL plus propres, mais relativement long, sachant que je n'ai pas trop de temps a consacrer à ces anciens projets, mais n'ayant pas envie de laisser des horreur pareils a mes futurs collègues je me demandais donc si vous aviez en tête une solution
plus clean à mon problème.

Merci d'avance pour les idées qui pourraient germer de vos esprits moins insalubres que le mien.

Cordialement

[Lordinaire]

J'aurai aussi rajouter une nouvelle méthode. C'est simple et ça ne t'oblige pas forcement à re-compiler tous tes anciens projets si ceux-ci n'utilise pas cette nouvelle méthode. Niveau compatibilité, tu n'auras ainsi pas à retoucher ton code sur tes anciens projets, chose que tu devras faire en cas de changement de signature de M1.

[Babyneedle]

Ne pas oublier de signifier aux futurs développeurs (même si c'est toi en théorie) que la vieille version est obsolète.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
using System;
 
public sealed class App {
   static void Main() {      
      // The line below causes the compiler to issue a warning: 
      // 'App.SomeDeprecatedMethod()' is obsolete: 'Do not call this method.'
      SomeDeprecatedMethod();
   }
 
   // The method below is marked with the ObsoleteAttribute.  
   // Any code that attempts to call this method will get a warning.
   [Obsolete("Do not call this method.")]
   private static void SomeDeprecatedMethod() { }
}