Génériques C # - Comment éviter la méthode redondante?

Supposons que j'ai deux classes qui ressemblent à ceci (le premier bloc de code et le problème général sont liés à C #):

class A 
{
    public int IntProperty { get; set; }
}

class B 
{
    public int IntProperty { get; set; }
}

Ces classes ne peuvent en aucun cas être modifiées (elles font partie d'un assemblage tiers). Par conséquent, je ne peux pas leur faire implémenter la même interface ou hériter de la même classe qui contiendrait alors IntProperty.

Je veux appliquer une logique sur la IntPropertypropriété des deux classes, et en C ++, je pourrais utiliser une classe de modèle pour le faire assez facilement:

template <class T>
class LogicToBeApplied
{
    public:
        void T CreateElement();

};

template <class T>
T LogicToBeApplied<T>::CreateElement()
{
    T retVal;
    retVal.IntProperty = 50;
    return retVal;
}

Et puis je pourrais faire quelque chose comme ça:

LogicToBeApplied<ClassA> classALogic;
LogicToBeApplied<ClassB> classBLogic;
ClassA classAElement = classALogic.CreateElement();
ClassB classBElement = classBLogic.CreateElement();   

De cette façon, je pouvais créer une seule classe d'usine générique qui fonctionnerait à la fois pour ClassA et ClassB.

Cependant, en C #, je dois écrire deux classes avec deux whereclauses différentes même si le code de la logique est exactement le même:

public class LogicAToBeApplied<T> where T : ClassA, new()
{
    public T CreateElement()
    {
        T retVal = new T();
        retVal.IntProperty = 50;
        return retVal;
    }
}

public class LogicBToBeApplied<T> where T : ClassB, new()
{
    public T CreateElement()
    {
        T retVal = new T();
        retVal.IntProperty = 50;
        return retVal;
    }
}

Je sais que si je veux avoir différentes classes dans la whereclause, elles doivent être liées, c'est-à-dire hériter de la même classe, si je veux leur appliquer le même code dans le sens que j'ai décrit ci-dessus. C'est juste qu'il est très ennuyeux d'avoir deux méthodes complètement identiques. Je ne veux pas non plus utiliser la réflexion à cause des problèmes de performances.

Quelqu'un peut-il suggérer une approche où cela peut être écrit d'une manière plus élégante?

Ajoutez une interface proxy (parfois appelée adaptateur , parfois avec des différences subtiles), implémentez-la LogicToBeApplieden termes de proxy, puis ajoutez un moyen de construire une instance de ce proxy à partir de deux lambdas: une pour la propriété get et une pour l'ensemble.

interface IProxy
{
    int Property { get; set; }
}
class LambdaProxy : IProxy
{
    private Function<int> getFunction;
    private Action<int> setFunction;
    int Property
    {
        get { return getFunction(); }
        set { setFunction(value); }
    }
    public LambdaProxy(Function<int> getter, Action<int> setter)
    {
        getFunction = getter;
        setFunction = setter;
    }
}

Maintenant, chaque fois que vous devez passer un IProxy mais avoir une instance des classes tierces, vous pouvez simplement passer quelques lambdas:

A a = new A();
B b = new B();
IProxy proxyA = new LambdaProxy(() => a.Property, (val) => a.Property = val);
IProxy proxyB = new LambdaProxy(() => b.Property, (val) => b.Property = val);
proxyA.Property = 12; // mutates the proxied `a` as well

De plus, vous pouvez écrire des aides simples pour construire des instances LamdaProxy à partir d'instances A ou B. Il peut même s'agir de méthodes d'extension pour vous donner un style "fluide":

public static class ProxyExtension
{
    public static IProxy Proxied(this A a)
    {
      return new LambdaProxy(() => a.Property, (val) => a.Property = val);
    }

    public static IProxy Proxied(this B b)
    {
      return new LambdaProxy(() => b.Property, (val) => b.Property = val);
    }
}

Et maintenant, la construction de procurations ressemble à ceci:

IProxy proxyA = new A().Proxied();
IProxy proxyB = new B().Proxied();

Quant à votre usine, je verrais si vous pouvez la refactoriser en une méthode d'usine "principale" qui accepte un IProxy et exécute toute la logique dessus et d'autres méthodes qui passent simplement new A().Proxied()ou new B().Proxied():

public class LogicToBeApplied
{
    public A CreateA() {
      A a = new A();
      InitializeProxy(a.Proxied());
      return a; // or maybe return the proxy if you'd rather use that
    }

    public B CreateB() {
      B b = new B();
      InitializeProxy(b.Proxied());
      return b;
    }

    private void InitializeProxy(IProxy proxy)
    {
        proxy.IntProperty = 50;
    }
}

Il n'y a aucun moyen de faire l'équivalent de votre code C ++ en C # car les modèles C ++ reposent sur un typage structurel . Tant que deux classes ont le même nom et la même signature de méthode, en C ++, vous pouvez appeler cette méthode de manière générique sur les deux. C # a un typage nominal - le nom d'une classe ou d'une interface fait partie de son type. Par conséquent, les classes Aet Bne peuvent pas être traitées de la même manière à quelque titre que ce soit, sauf si une relation explicite "est une" est définie par héritage ou implémentation d'interface.

Si la mise en œuvre de ces boilerplate méthodes par classe est trop, vous pouvez écrire une fonction qui prend un objet et pensivement construit un LambdaProxyen recherchant un nom de propriété spécifique:

public class ReflectiveProxier 
{
    public object proxyReflectively(object proxied)
    {
        PropertyInfo prop = proxied.GetType().GetProperty("Property");
        return new LambdaProxy(
            () => prop.GetValue(proxied),
            (val) => prop.SetValue(proxied, val));
     }
}

Cela échoue lamentablement quand on donne des objets de type incorrect; la réflexion introduit par nature la possibilité de défaillances que le système de type C # ne peut pas empêcher. Heureusement, vous pouvez éviter la réflexion jusqu'à ce que la charge de maintenance des assistants devienne trop importante, car vous n'êtes pas obligé de modifier l'interface IProxy ou la mise en œuvre de LambdaProxy pour ajouter le sucre réfléchissant.

Une partie de la raison pour laquelle cela fonctionne est qu'il LambdaProxyest "au maximum générique"; il peut adapter n'importe quelle valeur qui implémente "l'esprit" du contrat IProxy car l'implémentation de LambdaProxy est complètement définie par les fonctions getter et setter données. Cela fonctionne même si les classes ont des noms différents pour la propriété, ou différents types qui sont sensiblement et en toute sécurité représentables en tant que ints, ou s'il existe un moyen de mapper le concept qui Propertyest censé représenter à d'autres fonctionnalités de la classe. L'indirection fournie par les fonctions vous offre une flexibilité maximale.

Voici un aperçu de l'utilisation des adaptateurs sans hériter de A et / ou B, avec la possibilité de les utiliser pour les objets A et B existants:

interface IAdapter
{
    int Property { get; set; }
}

class LogicToBeApplied<T> where T : IAdapter, new()
{
    public T Create()
    {
        var ret = new T();
        ret.Property = 50;
        return ret;
    }
}

class AAdapter : IAdapter
{
    A _a;

    public AAdapter()  // use this if you want to have the "logic" part create new objects
    {
        _a=new A();
    }

    public AAdapter(A a) // if you need an adapter for an existing object afterwards
    {
       _a=a;
    }

    public int Property
    {
        get { return _a.Property; }
        set { _a.Property = value; }
    }

    public A {get{return _a; } } // to provide access for non-generic code
}

class BAdapter 
{
     // analogously
}

Je préfère généralement ce type d'adaptateur d'objet aux proxys de classe, ils évitent les problèmes laids que vous pouvez rencontrer avec l'héritage. Par exemple, cette solution fonctionnera même si A et B sont des classes scellées.

Vous pourriez vous adapter ClassAet ClassBvia une interface commune. De cette façon, votre code LogicAToBeAppliedreste le même. Pas très différent de ce que vous avez cependant.

class A
{
    public int Property { get; set; }
}
class B
{
    public int Property { get; set; }
}

interface IAdapter
{
    int Property { get; set; }
}

class LogicToBeApplied<T> where T : IAdapter, new()
{
    public T Create()
    {
        var ret = new T();
        ret.Property = 50;
        return ret;
    }
}

class AAdapter : A, IAdapter { }

class BAdapter : B, IAdapter { }

La version C ++ ne fonctionne que parce que ses modèles utilisent le «typage statique du canard» - tout est compilé tant que le type fournit les noms corrects. Cela ressemble plus à un système macro. Le système générique de C # et d'autres langages fonctionne très différemment.

Les réponses de devnull et de Doc Brown montrent comment le modèle d'adaptateur peut être utilisé pour garder votre algorithme général et continuer à fonctionner sur des types arbitraires… avec quelques restrictions. En particulier, vous créez maintenant un type différent de celui que vous souhaitez réellement.

Avec un peu de ruse, il est possible d'utiliser exactement le type prévu sans aucune modification. Cependant, nous devons maintenant extraire toutes les interactions avec le type cible dans une interface distincte. Ici, ces interactions sont la construction et l'attribution de propriété:

interface IInteractions<T> {
  T Instantiate();
  void AssignProperty(T target, int value);
}

Dans une interprétation de POO, ce serait un exemple du modèle de stratégie , bien que mélangé avec des génériques.

Nous pouvons ensuite réécrire votre logique pour utiliser ces interactions:

public class LogicBToBeApplied<T>
{
    public T CreateElement(IInteractions<T> interactions)
    {
        T retVal = interactions.Instantiate();
        interactions.AssignProperty(retVal, 50);
        return retVal;
    }
}

Les définitions d'interaction devraient ressembler à:

class Interactions_ClassA : IInteractions<ClassA> {
  public override ClassA Instantiate() { return new ClassA(); }
  public override void AssignProperty(ClassA target, int value) { target.IntProperty = value; }
}

Le gros inconvénient de cette approche est que le programmeur doit écrire et transmettre une instance d'interaction lors de l'appel de la logique. Ceci est assez similaire aux solutions basées sur un modèle d'adaptateur, mais est légèrement plus général.

D'après mon expérience, c'est le plus proche que vous pouvez obtenir des fonctions de modèle dans d'autres langues. Des techniques similaires sont utilisées dans Haskell, Scala, Go et Rust pour implémenter des interfaces en dehors d'une définition de type. Cependant, dans ces langues, le compilateur intervient et sélectionne implicitement l'instance d'interaction correcte afin que vous ne voyiez pas réellement l'argument supplémentaire. Ceci est également similaire aux méthodes d'extension de C #, mais n'est pas limité aux méthodes statiques.

Si vous voulez vraiment faire attention au vent, vous pouvez utiliser "dynamique" pour que le compilateur s'occupe de toutes les méchancetés de réflexion pour vous. Cela entraînera une erreur d'exécution si vous passez un objet à SetSomeProperty qui n'a pas de propriété nommée SomeProperty.

using System;

namespace ConsoleApplication3
{
    class A
    {
        public int SomeProperty { get; set; }
    }

    class B
    {
        public int SomeProperty { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var a = new A();
            var b = new B();

            SetSomeProperty(a, 7);
            SetSomeProperty(b, 12);

            Console.WriteLine($"a.SomeProperty = {a.SomeProperty}, b.SomeProperty = {b.SomeProperty}");
        }

        static void SetSomeProperty(dynamic obj, int value)
        {
            obj.SomeProperty = value;
        }
    }
}

Les autres réponses identifient correctement le problème et fournissent des solutions viables. C # ne prend pas (généralement) en charge le "typage du canard" ("S'il marche comme un canard ..."), il n'y a donc aucun moyen de forcer votre ClassAet ClassBd'être interchangeable s'il n'était pas conçu de cette façon.

Cependant, si vous êtes déjà prêt à accepter le risque d'une erreur d'exécution, il y a une réponse plus simple que d'utiliser Reflection.

C # a le dynamicmot - clé qui est parfait pour des situations comme celle-ci. Il indique au compilateur "Je ne saurai pas de quel type il s'agit avant l'exécution (et peut-être même pas à ce moment-là), alors permettez-moi de faire quoi que ce soit ".

En utilisant cela, vous pouvez créer exactement la fonction que vous souhaitez:

public class LogicToBeApplied<T> where T : new()
{
    public static T CreateElement()
    {
        dynamic retVal = new T(); // This doesn't care what type T is.
        retVal.IntProperty = 50;  // This will fail at runtime if there is no "IntProperty" 
                                  // or it doesn't accept an int.
        return retVal;            // Once again, we don't care what it is.
    }
}

Notez également l'utilisation du staticmot - clé. Cela vous permet de l'utiliser comme:

A classAElement = LogicToBeApplied<A>.CreateElement();
B classBElement = LogicToBeApplied<B>.CreateElement();

L' dynamicutilisation de la réflexion n'a aucune incidence sur les performances globales , la façon dont il y a le coup unique (et la complexité supplémentaire) de l'utilisation de la réflexion. La première fois que votre code frappera l'appel dynamique avec un type spécifique, il y aura une petite surcharge , mais les appels répétés seront tout aussi rapides que le code standard. Cependant, vous aurez obtenir un RuntimeBinderExceptionsi vous essayez de passer quelque chose qui n'a pas cette propriété, et il n'y a pas de bonne façon de vérifier que l' avance. Vous voudrez peut-être traiter spécifiquement cette erreur de manière utile.

Vous pouvez utiliser la réflexion pour extraire la propriété par son nom.

public class logic 
{
    public object getNew<T>() where T : new()
    {
        T ret = new T();
        try
        {
            var property = typeof(T).GetProperty("IntProperty");
            if (property != null && property.PropertyType == typeof(int))
            {
                property.SetValue(ret, 50);
            }
        }
        catch (AmbiguousMatchException)
        {
            //hmm..
        }
        return ret;
    }
}

Évidemment, vous risquez une erreur d'exécution avec cette méthode. C'est ce que C # essaie de vous empêcher de faire.

J'ai lu quelque part qu'une future version de C # vous permettra de passer des objets en tant qu'interface qu'ils n'héritent pas mais correspondent. Ce qui résoudrait également votre problème.

(Je vais essayer de déterrer l'article)

Une autre méthode, bien que je ne sois pas sûr qu'elle vous enregistre aucun code, serait de sous-classer A et B et d'hériter également d'une interface avec IntProperty.

public interface IIntProp {
    public int IntProperty {get, set}
}

public class A2 : A, IIntProp {}

public class B2 : B, IIntProp {}

Je voulais juste utiliser des implicit operatorconversions avec l'approche déléguée / lambda de la réponse de Jack. Aet Bsont tels que supposés:

// A and B are mutable reference types

class A
{
  public int IntProperty { get; set; }
}

class B
{
  public int IntProperty { get; set; }
}

Ensuite, il est facile d'obtenir une syntaxe agréable avec des conversions implicites définies par l'utilisateur (aucune méthode d'extension ou similaire n'est nécessaire):

// Adapter is an immutable type. However, the delegate instances have a captured reference to an A or a B (closure semantics)
struct Adapter
{
  readonly Func<int> getter;
  readonly Action<int> setter;

  Adapter(Func<int> getter, Action<int> setter)
  {
    this.getter = getter;
    this.setter = setter;
  }

  public int IntProperty
  {
    get { return getter(); }
    set { setter(value); }
  }

  public static implicit operator Adapter(A a) => new Adapter(() => a.IntProperty, x => a.IntProperty = x);
  public static implicit operator Adapter(B b) => new Adapter(() => b.IntProperty, x => b.IntProperty = x);

  public A CloneToA() => new A { IntProperty = getter(), };
  public B CloneToB() => new B { IntProperty = getter(), };
}

Illustration d'utilisation:

class LogicToBeApplied
{
  public static A CreateA()
  {
    var a = new A();
    Initialize(a);
    return a;
  }
  public static B CreateB()
  {
    var b = new B();
    Initialize(b);
    return b;
  }

  static void Initialize(Adapter a)
  {
    a.IntProperty = 50;
  }
}

La Initializeméthode montre comment vous pouvez travailler avec Adaptersans se soucier de savoir si c'est un Aou un Bou quelque chose d'autre. Les invocations de la Initializeméthode montrent que nous n'avons pas besoin de fonte (visible) .AsProxy()ou similaire pour traiter le béton Aou Bcomme un Adapter.

Demandez-vous si vous souhaitez lancer un ArgumentNullExceptiondans les conversions définies par l'utilisateur si l'argument passé est une référence nulle ou non.