C# imiter overridding de l'opérateur d'affectation (=)

Vous pourriez faire Wrapper<T> un struct. Cependant, je ne suis pas si sûr que ce serait fonction de la conception de votre application ou pas.

OriginalL'auteur zildjohn01

Ne pas implicitement exprimées votre enveloppe de deux manières.

public class DBValue<T>
{
    public static implicit operator DBValue <T>(T value)
    {
         return new DBValue<T>(value);
    }

    public static explicit operator T(DBValue <T> dbValue)
    {
         return dbValue.Value;
    }

    private readonly T _value;
    public T Value { get { this._value; } }

    public DBValue(T value)
    {
         this._value = value;
    }
}

Casting de DBValue<T> à T est une perte de conversion (au minimum, vous perdez le fait que c'est une valeur de la base de données), et par les meilleures pratiques devraient être explicites. Si vous n'avez pas de perdre quoi que ce soit par la conversion de DBValue<T> à T, vous pourriez tout aussi bien utiliser les propriétés de retour T.

Fondamentalement, vous avez déjà vu pourquoi vous ne devriez pas essayer de le faire: si un DBValue peut être remplacé par T et dans l'autre sens, comment le compilateur (ou développeur) savoir lequel choisir?

Nécessitant l'aval, les développeurs d'écrire:

string value = MyProperty.Value

ou

string value = (string)MyProperty

au lieu de

string value = MyProperty

...ce n'est pas contraignante, et permet de s'assurer que tout le monde sait exactement ce qu'il se passe.

EDIT:

Pour réellement répondre à la question, vous ne pouvez pas remplacer la référence à l'affectation ou à la faire ressembler que vous avez, mais vous ne devriez pas vraiment besoin.

OriginalL'auteur ajlane

Je viens de regarder, faire de la classe un struct est vraiment pas une option, car elle a une certaine logique dans le constructeur sans paramètre, en plus il hérite d'une classe abstraite, qui contient interne abstraite fonctions.

Je ne peux pas utiliser une interface, que ferait les fonctions publiques, ce qui permettrait de sortir de la logique entièrement.

Je peux poster l'ensemble de la classe si ce serait utile, mais il est un peu long (130 lignes)
Ou je pourrais jeter sur un autre serveur, si ce serait mieux ? (même si ça fait mal à l'intégrité de cette question, comme je peut le supprimer éventuellement à partir de ce serveur)

Aussi en train d'expliquer à la classe qui est vraiment difficile, sans l'écriture d'un essai complet :-/

De toute façon, je vais essayer d'illustrer le problème que je vais avoir.

Assumer 2 tableau des classes: CustomerTable et UserTable:

public class CustomerTable
{
  Wrapper<string> Name;
}

public class UserTable
{
  Wrapper<string> Name;
}

Maintenant, le problème est que certains autres développeurs peuvent utiliser le code ci-dessus comme suit:

CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();
user.Name = customer.Name; //This breaks my internal dictionary

Ce que le développeur doit, pour fonctionner, a été:

user.Name = (string)customer.Name;

Le problème est cependant, qui dans leur bon esprit de penser que, lors de l'écriture de code ?

Même si j'ai utilisé une Valeur de propriété, le développeur devra toujours se souvenir pour écrire

user.Name = customer.Name.Value; //or user.Name.Value = ....

Et, de nouveau, le développeur peut oublier cela, et tout d'un coup, il obtient des exceptions, ou pire: les données qui ne sont pas conservés dans la base de données.

Donc ma question est, que je veux le wrapper pour être totalement transparent (il devrait être utilisable comme si elle était en fait de la classe, du primitif, c'est l'emballage).
Cependant lors de l'attribution d'un wrapper pour l'autre, ma logique interne des pauses.

Ouf beaucoup de l'écriture, et beaucoup de code - permettez-moi de savoir si j'ai trop écrit.

OriginalL'auteur

Cet ancien relais de poste stills a besoin d'informations supplémentaires pour être complet. Il est évident qu'à l'origine le comportement souhaité ne peut être atteint, car l'opérateur = ne peut pas être surchargé, et de même C# ne peut pas être "trompé" dans le coulage d'un objet à son propre type... il va toujours se résument à une classe de référence de la mission. Mais Steffen en outre des postes de montrer à la classe Wrapper utilisé non pas seulement avec des variables locales, mais comme un champ de classe de type. Souhaité sémantique peut être utilisé ET l'intégrité du dictionnaire interne maintenue à l'aide des propriétés de la classe au lieu de champs publics.

---

Même en gardant l'original étant donné Wrapper<T> classe avec ses deux implicite opérateurs, voici le code qui fonctionne:

public class CustomerTable
{
    private Wrapper<string> _Name;
    public Wrapper<string> Name {
        get { return _Name; }
        set { _Name = (string)value; }
    }
}

public class UserTable
{
    private Wrapper<string> _Name;
    public Wrapper<string> Name {
        get { return _Name; }
        set { _Name = (string)value; }
    }
}

Si ce changement était fait, il ne serait pas briser code existant car il permet néanmoins de différents modes de définition de la propriété:

CustomerTable customer = new CustomerTable();
UserTable user = new UserTable();

user.Name = customer.Name; //*** No longer breaks internal data structures

user.Name = "string literal";  //Works as expected with implicit cast operator
user.Name = (string)customer.Name; //Still allowed with explicit/implicit cast operator
user.Name = customer.Name.Value; //Also works if Value property is still defined

Parce que ce n'est toujours pas la réponse à la question d'origine, l'utilisation de la classe Wrapper pourrait encore être problématique si utilisé à l'extérieur de la classe contexte de la propriété, c'est à dire passé entre l'objet, etc. Peut-être l'ensemble de la classe Wrapper pourraient être éliminés avec la bonne conception de classe, y compris l'utilisation de l'immeuble/accesseurs get.

OriginalL'auteur C Perkins