Comment utiliser la réflexion pour invoquer une méthode privée?

Il y a un groupe de méthodes privées dans ma classe, et je dois en appeler une dynamiquement en fonction d'une valeur d'entrée. Le code appelant et les méthodes cible se trouvent dans la même instance. Le code ressemble à ceci:

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType);
dynMethod.Invoke(this, new object[] { methodParams });

Dans ce cas, GetMethod()ne renverra pas de méthodes privées. Que BindingFlagsdois-je fournir pour GetMethod()qu'il puisse localiser des méthodes privées?

Modifiez simplement votre code pour utiliser la versionGetMethod surchargée qui accepte BindingFlags:

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType, 
    BindingFlags.NonPublic | BindingFlags.Instance);
dynMethod.Invoke(this, new object[] { methodParams });

Voici la documentation d'énumération BindingFlags .

BindingFlags.NonPublicne retournera aucun résultat par lui-même. Il s'avère que le combiner avec BindingFlags.Instancefait l'affaire.

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType, 
    BindingFlags.NonPublic | BindingFlags.Instance);

Et si vous voulez vraiment vous mettre en difficulté, rendez-le plus facile à exécuter en écrivant une méthode d'extension:

static class AccessExtensions
{
    public static object call(this object o, string methodName, params object[] args)
    {
        var mi = o.GetType ().GetMethod (methodName, System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance );
        if (mi != null) {
            return mi.Invoke (o, args);
        }
        return null;
    }
}

Et l'utilisation:

    class Counter
    {
        public int count { get; private set; }
        void incr(int value) { count += value; }
    }

    [Test]
    public void making_questionable_life_choices()
    {
        Counter c = new Counter ();
        c.call ("incr", 2);             // "incr" is private !
        c.call ("incr", 3);
        Assert.AreEqual (5, c.count);
    }

Microsoft a récemment modifié l'API de réflexion, rendant la plupart de ces réponses obsolètes. Les éléments suivants devraient fonctionner sur les plates-formes modernes (y compris Xamarin.Forms et UWP):

obj.GetType().GetTypeInfo().GetDeclaredMethod("MethodName").Invoke(obj, yourArgsHere);

Ou comme méthode d'extension:

public static object InvokeMethod<T>(this T obj, string methodName, params object[] args)
{
    var type = typeof(T);
    var method = type.GetTypeInfo().GetDeclaredMethod(methodName);
    return method.Invoke(obj, args);
}

Remarque:

• Si la méthode souhaitée se trouve dans une superclasse, objle Tgénérique doit être explicitement défini sur le type de la superclasse.

• Si la méthode est asynchrone, vous pouvez l'utiliser await (Task) obj.InvokeMethod(…).

Êtes-vous absolument sûr que cela ne peut pas se faire par héritage? La réflexion est la toute dernière chose à considérer lors de la résolution d'un problème, elle rend la refactorisation, la compréhension de votre code et toute analyse automatisée plus difficiles.

Il semble que vous devriez simplement avoir une classe DrawItem1, DrawItem2, etc. qui remplace votre dynMethod.

La réflexion en particulier sur les membres privés est fausse

• La réflexion rompt la sécurité du type. Vous pouvez essayer d'invoquer une méthode qui n'existe plus (ou plus), ou avec les mauvais paramètres, ou avec trop de paramètres, ou pas assez ... ou même dans le mauvais ordre (celui-ci mon préféré :)). Par ailleurs, le type de retour pourrait également changer.
• La réflexion est lente.

La réflexion des membres privés rompt le principe d' encapsulation et expose ainsi votre code aux éléments suivants:

• Augmentez la complexité de votre code car il doit gérer le comportement interne des classes. Ce qui est caché doit rester caché.
• Rend votre code facile à casser car il se compilera mais ne s'exécutera pas si la méthode a changé de nom.
• Rend le code privé facile à casser car s'il est privé, il n'est pas destiné à être appelé de cette façon. Peut-être que la méthode privée attend un état intérieur avant d'être appelée.

Et si je dois quand même le faire?

Il y a donc des cas, lorsque vous dépendez d'un tiers ou que vous avez besoin d'une API non exposée, vous devez faire quelques réflexions. Certains l'utilisent également pour tester certaines classes dont ils sont propriétaires mais qui ne veulent pas modifier l'interface pour donner accès aux membres internes uniquement pour les tests.

Si vous le faites, faites-le bien

• Atténuer la facilité de rupture:

Pour atténuer le problème facile à casser, le mieux est de détecter toute rupture potentielle en testant des tests unitaires qui s'exécuteraient dans une version d'intégration continue ou autre. Bien sûr, cela signifie que vous utilisez toujours le même assembly (qui contient les membres privés). Si vous utilisez une charge dynamique et une réflexion, vous aimez jouer avec le feu, mais vous pouvez toujours attraper l'exception que l'appel peut produire.

• Atténuez la lenteur de la réflexion:

Dans les versions récentes de .Net Framework, CreateDelegate battait d'un facteur 50 que MethodInfo invoquait:

// The following should be done once since this does some reflection
var method = this.GetType().GetMethod("Draw_" + itemType, 
  BindingFlags.NonPublic | BindingFlags.Instance);

// Here we create a Func that targets the instance of type which has the 
// Draw_ItemType method
var draw = (Func<TInput, Output[]>)_method.CreateDelegate(
                 typeof(Func<TInput, TOutput[]>), this);

drawles appels seront environ 50 fois plus rapides que l' MethodInfo.Invoke utilisation drawcomme standard Funccomme ça:

var res = draw(methodParams);

Consultez ce post pour voir des références sur différentes invocations de méthodes

Ne pourriez-vous pas simplement avoir une méthode Draw différente pour chaque type que vous souhaitez dessiner? Appelez ensuite la méthode Draw surchargée en passant l'objet de type itemType à dessiner.

Votre question ne précise pas si itemType fait réellement référence à des objets de types différents.

Je pense que vous pouvez le passer là BindingFlags.NonPublicoù c'est la GetMethodméthode.

Appelle n'importe quelle méthode malgré son niveau de protection sur l'instance d'objet. Prendre plaisir!

public static object InvokeMethod(object obj, string methodName, params object[] methodParams)
{
    var methodParamTypes = methodParams?.Select(p => p.GetType()).ToArray() ?? new Type[] { };
    var bindingFlags = BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static;
    MethodInfo method = null;
    var type = obj.GetType();
    while (method == null && type != null)
    {
        method = type.GetMethod(methodName, bindingFlags, Type.DefaultBinder, methodParamTypes, null);
        type = type.BaseType;
    }

    return method?.Invoke(obj, methodParams);
}

Lisez cette réponse (supplémentaire) (qui est parfois la réponse) pour comprendre où cela va et pourquoi certaines personnes dans ce fil se plaignent que "cela ne fonctionne toujours pas"

J'ai écrit exactement le même code que l'une des réponses ici . Mais j'avais toujours un problème. J'ai placé un point d'arrêt sur

var mi = o.GetType().GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance );

Il a exécuté mais mi == null

Et cela a continué comme ça jusqu'à ce que je "reconstruise" tous les projets impliqués. J'étais en train de tester un assemblage tandis que la méthode de réflexion était assise dans le troisième assemblage. C'était totalement déroutant, mais j'ai utilisé la fenêtre immédiate pour découvrir les méthodes et j'ai trouvé qu'une méthode privée que j'essayais de tester par unité avait un ancien nom (je l'ai renommé). Cela m'a dit que l'ancien assemblage ou PDB est toujours là même si le projet de test unitaire se construit - pour une raison quelconque, le projet qu'il n'a pas construit. "reconstruire" a fonctionné

BindingFlags.NonPublic