Créer une classe

Question

de chaîne personnalisée Je veux créer ma propre classe EMAILADDRESS qui agit comme une classe de chaîne.

J'aime le faire

private EMailAddress _emailAddress = "Test@Test.com"; 

au lieu de

private EMailAddress _emailAddress = new EMailAddress("Test@Test.com"); 

Est-il possible d'accomplir ce que je veux, ou dois-je utiliser la seconde alternative. Puisque chaîne Je ne peux pas utiliser est scellée que, et l'opérateur = ne peut pas être surchargé, donc je suis d'idées comment résoudre ce problème ....

Answer 1

Vous pouvez, avec une conversion implicit:

public class EMailAddress 
{ 
    private string _address; 

    public EMailAddress(string address) 
    { 
     _address = address; 
    } 

    public static implicit operator EMailAddress(string address) 
    { 
     // While not technically a requirement; see below why this is done. 
     if (address == null) 
      return null; 

     return new EMailAddress(address); 
    } 
} 

Les conversions implicites ne doivent être utilisées si aucune perte de données lors de la conversion. Même alors, je vous recommande d'utiliser cette fonctionnalité avec parcimonie, car cela peut rendre votre code plus difficile à lire.

Dans cet exemple, l'opérateur implicite renvoie null lorsqu'une chaîne null est transmise. Comme correctement Jon Hanna a commenté, il est souhaitable d'avoir ces deux extraits de code se comportent différemment:

// Will assign null to the reference 
EMailAddress x = null; 

// Would create an EMailAddress object containing a null string 
string s = null; 
EMailAddress y = s; 

Answer 2

Comme vous l'avez dit vous ne pouvez pas hériter de chaîne mais vous peut l'étendre avec des méthodes d'extension.

Vous pouvez donc faire des méthodes d'extension spécifiques de messagerie pour gérer quoi que ce soit que vous envisagez de mettre dans la classe EmailAddress.

Answer 3

vous faites cela en ajoutant un implicit operator from string à votre type personnalisé.

class EMailAddress 
{ 
     // ...other members 

     public static implicit operator EMailAddress (string address) 
     { 
      return new EMailAddress(address); 
     } 
} 

Cependant, je recommande d'utiliser ceci avec parcimonie.

Answer 4

Je pense que je vois ce que vous essayez de faire. Mais vous ne pouvez pas sous-classer string dans .NET. Parfois j'ai souhaité pouvoir sous-classer des types incorporés tels que int, mais bien sûr ce n'est pas possible non plus (bien que pour d'autres raisons techniques).

Alors que vous pourriez théoriquement utiliser une méthode de conversion implicit operator, comme suggéré par d'autres ici, il y a quelques problèmes avec ceux-ci, tels que les erreurs bizarre de compilateur de type. Cette solution n'a pas très bien fonctionné pour moi.

Ce que vous voyez habituellement dans la BCL dans des scénarios similaires — à savoir quand un type spécialisé devrait « se sentir » comme le type il est basé sur — est un type personnalisé ayant une Value propriété. (Deux exemples qui viennent à l'esprit sont System.Nullable<T>, System.Lazy<T>.) Ce n'est pas aussi élégant, mais cela fonctionne. Un opérateur implicite doit convertir une valeur null en une autre valeur nulle, sauf si le type cast n'est pas Nullable, auquel cas il doit être erroné sur null.

Answer 5

2. S'il vous plaît, si vous écrivez quelque chose qui contient un Uri, ne forcez pas les gens qui l'utilisent à avoir un Uri à faire le travail pour obtenir la chaîne pour eux-mêmes. Les adresses e-mail s'adaptent naturellement à mailto: uris, alors que ce n'est pas tout à fait un exemple, c'est proche.

Exemple:

public class EmailAddress 
{ 
    private string _value; 
    private static bool IsValidAddress(string address) 
    { 
     //whether to match RFC822 production or have something simpler, 
     //but excluding valid but unrealistic addresses, is an impl. choice 
     //out of scope. 
     return true; 
    } 
    public EMailAddress(string value) 
    { 
     if(value == null) 
      throw new ArgumentNullException(); 
     if(!IsValidAddress(value)) 
      throw new ArgumentException(); 
     _value = value; 
    } 
    public EmailAddress(Uri uri) 
    { 
     if(value == null) 
      throw new ArgumentNullException(); 
     if(!uri.Scheme != "mailto") 
      throw new ArgumentException(); 
     string extracted = uri.UserInfo + "@" + uri.Host; 
     if(!IsValidAddress(extracted)) 
      throw new ArgumentException(); 
     _value = extracted; 
    } 
    public override string ToString() 
    { 
     return _value; 
    } 
    public static implicit operator EMailAddress(string value) 
    { 
     return value == null ? null : new EMailAddress(value); 
    } 
    public static implicit operator EMailAddress(Uri uri) 
    { 
     return value == null ? null : new EMailAddress(uri); 
    } 
} 

Answer 6

Je pense que cette question est un cas particulier d'une question plus générale sur la création de sécurité de type à travers une application C#. Mon exemple ici est avec 2 types de données: les prix et les poids. Ils ont différentes unités de mesure, donc on ne devrait jamais essayer d'attribuer un prix à un poids ou vice versa. Les deux sous les couvertures sont vraiment des valeurs décimales. (J'ignore le fait qu'il pourrait y avoir des conversions comme des livres en kilogrammes etc.) Cette même idée pourrait être appliquée aux chaînes avec des types spécifiques comme EmailAddress et UserLastName. Avec un peu de code de plaque de chaudière, on peut effectuer une conversion explicite ou des conversions implicites entre les types spécifiques: Prix et Poids, et le type sous-jacent Décimal. Avec les remplacements d'opérateurs "explicites", on obtient un ensemble plus restrictif de choses que l'on peut faire avec ces classes. Vous devez être manuellement cas chaque fois que vous passez d'un type à l'autre. Par exemple:

public void NeedsPrice(Price aPrice) 
    { 
    } 

    public void NeedsWeight(Weight aWeight) 
    { 
    } 

    public void NeedsDecimal(Decimal aDecimal) 
    { 
    } 
    public void ExplicitTest() 
    { 

     Price aPrice = (Price)1.23m; 
     Decimal aDecimal = 3.4m; 
     Weight aWeight = (Weight)132.0m; 

     // ok 
     aPrice = (Price)aDecimal; 
     aDecimal = (Decimal)aPrice; 

     // Errors need explicit case 
     aPrice = aDecimal; 
     aDecimal = aPrice; 

     //ok 
     aWeight = (Weight)aDecimal; 
     aDecimal = (Decimal) aWeight; 

     // Errors need explicit cast 
     aWeight = aDecimal; 
     aDecimal = aWeight; 

     // Errors (no such conversion exists) 
     aPrice = (Price)aWeight; 
     aWeight = (Weight)aPrice; 

     // Ok, but why would you ever do this. 
     aPrice = (Price)(Decimal)aWeight; 
     aWeight = (Weight)(Decimal)aPrice; 

     NeedsPrice(aPrice); //ok 
     NeedsDecimal(aPrice); //error 
     NeedsWeight(aPrice); //error 

     NeedsPrice(aDecimal); //error 
     NeedsDecimal(aDecimal); //ok 
     NeedsWeight(aDecimal); //error 

     NeedsPrice(aWeight); //error 
     NeedsDecimal(aWeight); //error 
     NeedsWeight(aWeight); //ok 
    } 

changeant seulement les opérateurs « explicites » les opérateurs à « implicites » en remplaçant les mots « explicite » par « implicite » dans le code, on peut convertir dans les deux sens à la classe décimale sous-jacente sans travail supplémentaire. Cela fait que le prix et le poids se comportent plus comme une décimale, mais vous ne pouvez toujours pas modifier un prix par rapport à un poids. C'est généralement le niveau de sécurité que je recherche. Lorsque vous effectuez cette opération pour Chaîne au lieu de Décimal,

public void ImplicitTest() 
    { 
     Price aPrice = 1.23m; 
     Decimal aDecimal = 3.4m; 
     Weight aWeight = 132.0m; 

     // ok implicit cast 
     aPrice = aDecimal; 
     aDecimal = aPrice; 

     // ok implicit cast 
     aWeight = aDecimal; 
     aDecimal = aWeight; 

     // Errors 
     aPrice = aWeight; 
     aWeight = aPrice; 


     NeedsPrice(aPrice); //ok 
     NeedsDecimal(aPrice); //ok 
     NeedsWeight(aPrice); //error 

     NeedsPrice(aDecimal); //ok 
     NeedsDecimal(aDecimal); //ok 
     NeedsWeight(aDecimal); //ok 

     NeedsPrice(aWeight); //error 
     NeedsDecimal(aWeight); //ok 
     NeedsWeight(aWeight); //ok 
    }  

J'aime l'idée de la réponse de Thorarin à propos de la vérification de null et du retour de null dans la conversion. par exemple.

public static implicit operator EMailAddress(string address) 
{ 
    // Make 
    //  EmailAddress myvar=null 
    // and 
    //  string aNullString = null; 
    //  EmailAddress myvar = aNullString; 
    // give the same result. 
    if (address == null) 
     return null; 

    return new EMailAddress(address); 
} 

Pour obtenir ces classes de travail en tant que clés de collections dictionnaire, vous aurez également besoin d'implémenter equals, GetHashCode, == opérateur, et l'opérateur! =

Pour rendre tout cela plus facile, je fis classe ValueType que je peux étendre, La classe ValueType appelle le type de base pour tout sauf les opérateurs de conversion.