Arguments pour l'utilisation de String

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.

Citation:

---

Envoyé par ericover

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" :aie:. L'argumentation de tes collègues en faveur de la réinvention de la roue me paraît bien faible :mrgreen:

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 ;)

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...

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

Code:

---

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

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 ?

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...

Le principal argument est que leur argument ne tient pas :aie:

Merci Davcha!
Par contre avec la définition de l'opérateur implicit dans notre classe comme ceci:

Code:

---

1 2 3 4 5 6 7 8

class MonStringPerso { ... public static implicit operator string(MonStringPerso s1) { return s1.ToString(); } }

---

On peut après utiliser notre type perso de facon transparente partout où est attendu un type string.
Exemple:

Code:

---

1 2 3

MonStringPerso s_perso = new MonStringPerso("toto");   IDataConnection.Connect(s_perso);

---

Y'a-t-il d'après vous des "contre-indications" à utiliser cet opérateur ?

PitMaverick78,
Un autre de leurs arguments est d'avoir une classe unique où toutes les méthodes sont définies et ne pas avoir à chercher les méthodes une fois dans String puis dans une classe StringExtensions....

Citation:

---

Envoyé par ericover

Un autre de leurs arguments est d'avoir une classe unique où toutes les méthodes sont définies et ne pas avoir à chercher les méthodes une fois dans String puis dans une classe StringExtensions....

---

Avec l'Intellisense, ils n'y verront que du feu, ce sera totalement transparent ;)

Oui, sauf pour ceux qui ont l'habitude de lire le fichier .h (ou .hpp) pour voir la liste des fonctions disponibles...

Citation:

---

Envoyé par ericover

Oui, sauf pour ceux qui ont l'habitude de lire le fichier .h (ou .hpp) pour voir la liste des fonctions disponibles...

---

Il y a aussi le "Class View" qui te permet de voir toutes les fonctions disponibles au sein d'une classe...

Citation:

---

Envoyé par ericover

Oui, sauf pour ceux qui ont l'habitude de lire le fichier .h (ou .hpp) pour voir la liste des fonctions disponibles...

---

De toute facon y'a pas de .h ou .hpp :D

Edit:
ca me fait penser aux gens qui nomment leur objets en C# en fonction du type genre bMyVar pour un booleen, etc.
Ok, dans des environnements sans Intellisense, ca se comprend mais sur Visual Studio, beurk! En plus au refactoring c'est plus galère qu'autre chose (si par exemple ta variable change de type, faut changer le nom)

A propos du "Class View", celui-ci n'affiche que les méthodes de "String" par exemple. Les méthodes d'extension ne sont pas affichées sous "String".
Ce qu'il me faudrait c'est pouvoir voir d'un coup la liste des méthodes de String et toutes ses extensions. Peux-t-être avec un outil de génération de documentation ?

L'Object Browser fait ça.

Est-ce que les méthodes d'extension que j'ai défini pour string sont censés s'afficher directement dans la listes des membres de string ? Si oui je n'y arrive pas malgré avoir sélectionné l'option d'affichage des membres d'extension...