Comment puis-je remplacer les types de base comme les entiers, les chaînes, etc.?

Question

Je suis en train d'étendre certains des types de données de base dans vb.net pour une grande application. En l'état, mes nouveaux objets de type de données ont des noms comme MYInteger et MYString. Puisque ce sont les seuls types que j'utilise pour mon application et qu'ils sont principalement compatibles avec les types par défaut, est-il possible de remplacer les valeurs par défaut avec les miennes alors quand vous utilisez Dim iThing as Integer mon type entier légèrement personnalisé?

Answer 1

Non. Si vous le pouvez, imaginez alors le chaos que cela causerait. Il y aurait deux possibilités dans ce scénario:

1. Tout le code en cours d'exécution dans le même processus utiliserait ces types, même le code qui ne s'y attend pas. Mal. Votre concept d'un Integer est différent du concept du CLR d'un Integer, et soudain deux objets du même type sont différents. Mal.

Vous pouvez ajouter des méthodes d'extension à des types scellés. Quelque chose comme:

Module MyExtensions 
    <Extension()> 
    Public Function Extended(i as Integer) As Integer 
     return i + 4 
    End Function 
End Module 

4.Extended() ' evaluates to 8 

Answer 2

Je ne suis pas sûr si vous voulez vraiment faire cela. Cela rendra plus difficile le maintien dans le futur. Pourquoi ne pas utiliser MyInteger, etc? Si vous importez du code source externe, faites simplement une recherche & remplacer.

Answer 3

Je ne sais pas si elle applique dans votre cas, mais parfois les gens veulent faire ce qui équivaut à scalaires/types primitifs « spécialisés ». Par exemple, voir certains types définis dans this codeplex project. Certains des types comprennent Latitude, Longitude, Angle, etc. Chacun de ces types est en fait une structure avec un seul élément de données, généralement un double, flotteur ou int/long, comme celui-ci:

public struct Latitude : IFormattable, IComparable<Latitude>, IEquatable<Latitude> 
{ 
    private readonly double _DecimalDegrees; 

    //Some constants 

    //Some constructors 

    //Some static fields like... 
    public static readonly Latitude Equator = new Latitude(0.0); 
    public static readonly Latitude TropicOfCapricorn = new Latitude(-23.5); 
    public static readonly Latitude TropicOfCander = new Latitude(23.5); 

    //Some operators 
    public static Latitude operator +(Latitude left, Latitude right) 
    { 
    return new Latitude(left.DecimalDegrees + right.DecimalDegrees); 
    } 

    public static Latitude operator +(Latitude left, double right) 
    { 
    return new Latitude(left.DecimalDegrees + right); 
    } 
} 

Techniquement , ces types sont juste classe ou structs (principalement structs dans le cas du projet lié), mais ils sont utilisés pour représenter des valeurs qui sont souvent (habituellement ?, presque toujours ??) simplement des valeurs scalaires. Si vous avez un objet qui a une propriété Angle, la plupart des gens feraient probablement un double.

public MyObject 
{ 
    public double AngleInDegrees { set; get; } 
} 

Lorsqu'une valeur est affectée à AngleInDegrees, MyObject pourrait vouloir faire un peu de traitement:

public double AngleInDegrees 
{ 
    get 
    { 
    return _AngleInDegrees; 
    } 
    set 
    { 
    if (value < 0 || value > 360) 
    { 
     _AngleInDegrees = NormalizeAngle(value); 
    } 
    else 
    { 
     _AngleInDegrees = value; 
    } 
    } 
} 

si vous aviez une propriété AngleInDegrees sur de nombreux objets? Que faire si vous avez une classe qui consomme des angles produits par d'autres composants dans votre application? Qui devrait faire la validation? Il est utile de pouvoir toujours travailler avec de "bons" angles? En ayant un type AngleInDegrees, il devient possible de mettre toutes les opérations de validation et spéciales "Angle" dans le type. Il devient également possible de taper fortement tous les endroits où vous voulez utiliser AngleInDegrees.

Comme je l'ai dit, je ne sais pas si c'est le genre de chose que vous essayez d'accomplir ou non. En lisant votre question, j'ai eu l'impression que j'avais la même pensée lorsque j'ai vu pour la première fois le projet auquel je m'associais (c.-à-d.qu'il semblait en effet qu'ils étaient en train de sous-classer les types de données primitifs pour faire des types primitifs plus restrictifs).