Discussion :

[ericover]

Bonjour,

Je travaille dans une société de construction de machines industrielles. Cette société développe un logiciel pour ces machines en C++ depuis plus de 10 ans. Aujourd'hui, afin de moderniser l'application il a été décidé de revoir entièrement le design de l'interface graphique. Celle-ci sera réalisée en WPF par une équipe de designer externe à la société. Nous allons donc redévelopper dans un premier temps l'ensemble de nos bibliothèques utiles dans par l'interface graphique en C#.
Personnellement, j'ai déjà une expérience de quelques années en développement en C#, contrairement à mes collègues qui ne connaissent pour l'instant que le C++. Notre développement vient à peine de débuter que nous nous trouvons déjà en conflit. En effet je désire utiliser directement le type String du Framework .NET. Or vu qu'il n'est pas possible de dériver String et de rajouter nos propres méthodes, mes collègues souhaitent développer une nouvelle classe qui contient une variable membre String et ainsi définir et n'utiliser que leurs propres méthodes. Je leur ai évidémment dit qu'il était possible de rajouter des méthodes à String grâce aux méthodes d'extension, mais cette solution ne leur plaît pas esthétiquement.
Avez-vous des arguments pouvant m'aider à leur faire comprendre que c'est une mauvaise idée de vouloir redévelopper une classe gérant les chaînes de caractères ? De plus, mes collègues souhaiteraient appliquer ce principe à l'ensemble des types .NET que nous utiliserons et qui ne peuvent être hérités.
Merci de votre aide.

[Max]

Or vu qu'il n'est pas possible de dériver String et de rajouter nos propres méthodes, mes collègues souhaitent développer une nouvelle classe qui contient une variable membre String et ainsi définir et n'utiliser que leurs propres méthodes. Je leur ai évidemment dit qu'il était possible de rajouter des méthodes à String grâce aux méthodes d'extension, mais cette solution ne leur plaît pas esthétiquement.

Salut.

Un mot m'interpelle : "esthétiquement" . L'argumentation de tes collègues en faveur de la réinvention de la roue me paraît bien faible

Si les méthodes d'extension ont été créées, c'est bel et bien parce qu'elles sont d'une grande utilité ! Avec tout le respect que j'ai pour tes collègues, ça sent à plein nez les vieux briscards du C++ qui acceptent malgré eux de changer de langage mais qui veulent continuer à développer avec des méthodes C++. A mes yeux, soit ils utilisent le C# avec ses avantages et ses inconvénients, soit ils continuent à faire du C++, point barre. Mais mélanger les deux, ça me semble totalement incongru.

Et puis je parle même pas du temps que vous allez passer inutilement à développer tout ça...

Je te souhaite bien du courage

[ericover]

Merci,

En fait, l'idée de passer à C# n'a pas été un problème. Celle-ci avait même été prise avant mon arrivée dans la société. Ce qu'il manque surtout à mes collègues c'est du temps libre pour se former à .NET pour voir ce qu'est vraiment .NET.
Sachant qu'ils souhaitaient conserver leur architecture et leurs bibliothèques, je leur avait suggéré de programmer l'interface graphique en C++/CLI, mais là, la crainte qu'ils ont c'est d'avoir du code trop compliqué et pas performant dû aux conversions entre managé et non managé.
Le comble dans tout ca, c'est que la décision de passer en C# a été prise avec l'idée de pouvoir accélérer les temps de développement...

[Nathanael Marchand]

En effet les méthodes d'extension sont la solution!
Exemple:

Code :

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

1
2
3
4
public static String JeFaisKeskeJeVeux(this String myString)
{
   return "pouet"+myString+"pouet";
}

Ca étend String et ca lui rajoute la méthode JeFaisKeskeJeVeux

[ericover]

Merci !
Mais ce dont j'aurai plutôt besoin c'est un ensemble d'arguments contre la solution de développer nos propres classes. Il y a déjà le temps de développement, de tests. Mais y'en a-t-il d'autres ? Que risque-t-on de perdre en utilisant un type spécifique plutôt que String ?

[davcha]

Il y a pas mal de méthodes qui utilisent des string en paramètre dans le framework.
Pour n'en citer qu'un : IDataConnection.Connect(string)...

Alors, utiliser un type encapsulant un string... C'est une bonne manière d'obscurcir le code inutilement...

C'est comme s'ils décidaient de créer des classes pour le type int ou char, en C++, parce que ce sont des types primitif qu'on ne peut pas dériver...