Par exemple, vous souhaitez qu'un objet soit éventuellement initialisé de deux manières, en utilisant un chemin de fichier et à l'aide d'une chaîne. Normalement, les deux constructeurs doivent prendre un paramètre de chaîne, modifier : Dans le premier cas, le chemin de fichier est également nécessaire, veuillez donc ne pas suggérer une solution qui lit le contenu du fichier et simplement transmettre le contenu à l'autre constructeur. myObject (fichier de chaîne) et myObject (Centre de chaîne) , mais il est impossible de surcharger de cette façon. Que suggérez-vous?
7 Réponses :
Peut-être que vous pourriez peut-être changer le premier à accepter un FileInfo à la place:
Ou plus généralement, enveloppez l'un des types de chaîne dans sa propre classe et acceptez le type de paramètre (dans ce cas, le wrapper est fileinfo)
Je ne suis pas un programmeur C #, mais cela ressemble à un travail pour le Méthode d'usine statique motif: alors vous pouvez faire qui est encore plus lisible que d'utiliser un constructeur ordinaire. < / p>
Dans le second cas, j'ai toujours besoin de la voie que je vais perdre si j'utilise ce modèle.
Vous avez ce problème quand même? Pourquoi ne pas avoir myObject.getpath () qui retourne null si MyObject n'a pas été créé à partir d'un chemin?
@Louis: Créez un setter privé pour le chemin que myObject.fromfile () peut utiliser pour stocker cette information ou avoir une surcharge de constructeur privé qui prend un paramètre factice supplémentaire pour indiquer que la chaîne est un chemin - celles-ci pourraient être des verrues dans la conception. , mais comme ils sont privés et que l'interface publique qui en résulte est agréable et propre, cela pourrait être un compromis raisonnable.
ou créer des méthodes d'usine:
Peut-être que vous pouvez utiliser une usine?
class MyObjectProvider
{
public static MyObject CreateByPath(string path)
{
return new MyObject
{
Path = path;
};
}
public static MyObject CreateByContent(string content)
{
return new MyObject
{
Content = content;
};
}
}
public MyObject(Uri fileUri); public MyObject(string content);
Je pense que vous référez cette question. ::
Appelant la surcharge du constructeur lorsque les deux surcharge ont la même signature
Je vais prendre l'approche contrarian et dire ne le faites pas. Le meilleur des solutions affichées jusqu'à présent (utilisez un autre type de type tel que FileInfo ou URI pour l'une des surcharges) semble un peu piraquable à moi - va à l'encontre du principe de la moins surprise.
Si vous pouvez construire à l'aide du contenu uniquement Sans nom de fichier, il s'ensuit que le nom de fichier n'est pas essentiel. De même, si vous pouvez construire avec un nom de fichier, il s'ensuit que le contenu n'est pas essentiel. Vous pouvez probablement définir ultérieurement le nom de fichier / contenu manquant ultérieurement, par exemple. En définissant une propriété: p> au lieu d'essayer de le combattre, choisissez l'un de vos paramètres comme étant le plus important (nom de fichier dans l'exemple suivant) et créer deux constructeurs comme Suit: P> public MyObject(string fileName, string content)
{
if (fileName == null && content == null) throw new ArgumentException(...);
...
}
Enveloppez l'un des types de chaîne dans sa propre classe et acceptez plutôt que le type de paramètre.
@Cody Grey: Bonjour, je pense que cela mérite d'être une réponse.
Je ne l'ai pas posté comme une réponse parce que je pense que celui fourni par Mark Byers est la meilleure solution dans ce cas. (J'ai suscité celui-là.) Aucune raison de créer une classe d'emballage supplémentaire lorsqu'il y a un type intégré qui fera le travail. Pour des applications plus générales, ma suggestion est probablement la voie à suivre.
J'irais pour la méthode statique de l'usine ou créer un constructeur qui accepte les deux arguments et jette une exception si les deux arguments sont! = Null. Je dis cela parce que pas toujours (mon cas - j'ai un problème similaire), les types sont vraiment des cordes et je ne trouve pas particulièrement élégant de jeter une nouvelle classe qui représente une chaîne