Contrainte de type multiple (OR) de méthode générique

En lisant ceci , j'ai appris qu'il était possible d'autoriser une méthode à accepter des paramètres de plusieurs types en en faisant une méthode générique. Dans l'exemple, le code suivant est utilisé avec une contrainte de type pour s'assurer que "U" est un IEnumerable<T>.

public T DoSomething<U, T>(U arg) where U : IEnumerable<T>
{
    return arg.First();
}

J'ai trouvé un peu plus de code qui permettait d'ajouter plusieurs contraintes de type, telles que:

public void test<T>(string a, T arg) where T: ParentClass, ChildClass 
{
    //do something
}

Cependant, ce code semble appliquer qui argdoit être à la fois un type de ParentClass et ChildClass . Ce que je veux faire, c'est dire que arg pourrait être un type de ParentClass ou ChildClass de la manière suivante:

public void test<T>(string a, T arg) where T: string OR Exception
{
//do something
}

Votre aide est appréciée comme toujours!

Ce n'est pas possible. Vous pouvez cependant définir des surcharges pour des types spécifiques:

public void test(string a, string arg);
public void test(string a, Exception arg);

Si ceux-ci font partie d'une classe générique, ils seront préférés à la version générique de la méthode.

La réponse de Botz est correcte à 100%, voici une courte explication:

Lorsque vous écrivez une méthode (générique ou non) et déclarez les types des paramètres que la méthode prend, vous définissez un contrat:

Si vous me donnez un objet qui sait comment faire l'ensemble des choses que le Type T sait faire, je peux fournir soit 'a': une valeur de retour du type que je déclare, soit 'b': une sorte de comportement qui utilise ce type.

Si vous essayez de lui donner plus d'un type à la fois (en ayant un ou) ou essayez de le faire renvoyer une valeur qui pourrait être plus d'un type, ce contrat devient flou:

Si vous me donnez un objet qui sait sauter à la corde ou qui sait calculer pi au 15e chiffre, je retournerai soit un objet qui peut aller à la pêche, soit peut-être mélanger du béton.

Le problème est que lorsque vous entrez dans la méthode, vous ne savez pas s'ils vous ont donné un IJumpRopeou un PiFactory. De plus, lorsque vous utilisez la méthode (en supposant que vous l'avez compilée par magie), vous ne savez pas vraiment si vous avez un Fisherou unAbstractConcreteMixer . Fondamentalement, cela rend le tout beaucoup plus déroutant.

La solution à votre problème est l'une des deux possibilités:

1. Définissez plusieurs méthodes qui définissent chaque transformation, comportement ou autre. C'est la réponse de Botz. Dans le monde de la programmation, on parle de surcharge de la méthode.

2. Définissez une classe ou une interface de base qui sait comment faire tout ce dont vous avez besoin pour la méthode et une seule méthode prend juste ce type. Cela peut impliquer de regrouper un stringet Exceptiondans une petite classe pour définir comment vous prévoyez de les mapper à l'implémentation, mais tout est alors très clair et facile à lire. Je pourrais venir, dans quatre ans, lire votre code et comprendre facilement ce qui se passe.

Ce que vous choisissez dépend de la complexité des choix 1 et 2 et de leur capacité d'extension.

Donc, pour votre situation spécifique, je vais imaginer que vous sortez simplement un message ou quelque chose de l'exception:

public interface IHasMessage
{
    string GetMessage();
}

public void test(string a, IHasMessage arg)
{
    //Use message
}

Maintenant, tout ce dont vous avez besoin, ce sont des méthodes qui transforment a stringet an Exceptionen IHasMessage. Très facile.

Si ChildClass signifie qu'il est dérivé de ParentClass, vous pouvez simplement écrire ce qui suit pour accepter à la fois ParentClass et ChildClass;

public void test<T>(string a, T arg) where T: ParentClass 
{
    //do something
}

D'un autre côté, si vous souhaitez utiliser deux types différents sans relation d'héritage entre eux, vous devez considérer les types implémentant la même interface;

public interface ICommonInterface
{
    string SomeCommonProperty { get; set; }
}

public class AA : ICommonInterface
{
    public string SomeCommonProperty
    {
        get;set;
    }
}

public class BB : ICommonInterface
{
    public string SomeCommonProperty
    {
        get;
        set;
    }
}

alors vous pouvez écrire votre fonction générique comme;

public void Test<T>(string a, T arg) where T : ICommonInterface
{
    //do something
}

Aussi vieille que cette question soit, je reçois toujours des votes positifs aléatoires sur mon explication ci-dessus. L'explication tient toujours parfaitement bien telle quelle, mais je vais répondre une deuxième fois avec un type qui m'a bien servi en tant que substitut aux types d'union (la réponse fortement typée à la question qui n'est pas directement prise en charge par C # tel quel ).

using System;
using System.Diagnostics;

namespace Union {
    [DebuggerDisplay("{currType}: {ToString()}")]
    public struct Either<TP, TA> {
        enum CurrType {
            Neither = 0,
            Primary,
            Alternate,
        }
        private readonly CurrType currType;
        private readonly TP primary;
        private readonly TA alternate;

        public bool IsNeither => currType == CurrType.Primary;
        public bool IsPrimary => currType == CurrType.Primary;
        public bool IsAlternate => currType == CurrType.Alternate;

        public static implicit operator Either<TP, TA>(TP val) => new Either<TP, TA>(val);

        public static implicit operator Either<TP, TA>(TA val) => new Either<TP, TA>(val);

        public static implicit operator TP(Either<TP, TA> @this) => @this.Primary;

        public static implicit operator TA(Either<TP, TA> @this) => @this.Alternate;

        public override string ToString() {
            string description = IsNeither ? "" :
                $": {(IsPrimary ? typeof(TP).Name : typeof(TA).Name)}";
            return $"{currType.ToString("")}{description}";
        }

        public Either(TP val) {
            currType = CurrType.Primary;
            primary = val;
            alternate = default(TA);
        }

        public Either(TA val) {
            currType = CurrType.Alternate;
            alternate = val;
            primary = default(TP);
        }

        public TP Primary {
            get {
                Validate(CurrType.Primary);
                return primary;
            }
        }

        public TA Alternate {
            get {
                Validate(CurrType.Alternate);
                return alternate;
            }
        }

        private void Validate(CurrType desiredType) {
            if (desiredType != currType) {
                throw new InvalidOperationException($"Attempting to get {desiredType} when {currType} is set");
            }
        }
    }
}

La classe ci - dessus représente un type qui peut être soit TP ou TA. Vous pouvez l'utiliser comme tel (les types renvoient à ma réponse d'origine):

// ...
public static Either<FishingBot, ConcreteMixer> DemoFunc(Either<JumpRope, PiCalculator> arg) {
  if (arg.IsPrimary) {
    return new FishingBot(arg.Primary);
  }
  return new ConcreteMixer(arg.Secondary);
}

// elsewhere:

var fishBotOrConcreteMixer = DemoFunc(new JumpRope());
var fishBotOrConcreteMixer = DemoFunc(new PiCalculator());

Notes IMPORTANTES:

• Vous obtiendrez des erreurs d'exécution si vous ne cochez pas IsPrimary abord.
• Vous pouvez vérifier l'un des fichiers IsNeither IsPrimaryou IsAlternate.
• Vous pouvez accéder à la valeur via PrimaryetAlternate
• Il existe des convertisseurs implicites entre TP / TA et Either pour vous permettre de transmettre soit les valeurs, soit un Eithern'importe où où l'on est attendu. Si vous faites passer un Eitheroù un TAou TPdevrait, mais Eithercontient le mauvais type de valeur que vous obtiendrez une erreur d'exécution.

J'utilise généralement ceci où je veux qu'une méthode renvoie un résultat ou une erreur. Cela nettoie vraiment ce code de style. J'utilise aussi très occasionnellement ( rarement ) ceci en remplacement des surcharges de méthode. En réalité, c'est un très mauvais substitut à une telle surcharge.