L'accès à un Constructeur Privé de l'Extérieur de la Classe en C#

Si je définir une classe avec un constructeur par défaut et un constructeur public qui a des paramètres, comment puis-je accéder au constructeur privé? 

public class Bob
{
   public String Surname { get; set; }

   private Bob()
   { }

   public Bob(string surname)
   {
      Surname = surname;
   }
}

Je peux accéder au constructeur privé via une méthode statique de la classe comme ceci:

public static Bob GetBob()
{
   return new Bob();
}

J'ai pensé que je pouvais accéder au constructeur privé via une méthode d'extension, puisque (selon ma compréhension) les méthodes d'extension sont convertis afin qu'ils semblent être méthodes statiques de la classe, mais je ne peux pas:

static class Fred
{
   public static Bob Bobby(this Bob bob)
   {
      return new Bob();
   }
}

Alors, comment puis-je accéder au constructeur privé?

Merci

EDIT:

La raison que j'ai voulu faire ce que je voulais créer des tests pour l'un de nos classes, mais de ne pas permettre à un consommateur de cette classe pour pouvoir instancier un objet de manière incorrecte. Je suis en essais, donc je sais (j'espère!) dans quelles circonstances les tests échouent. Je suis encore un test de n00b maintenant donc, mon idée peut ou peut ne pas avoir été dans le "mauvais sens" de faire les choses.

J'ai changé ma stratégie de test pour juste faire les choses de la façon dont les consommateurs de cette classe, c'est à dire d'appeler les méthodes publiques et si les méthodes publiques sont OK, en supposant que les méthodes privées sont OK. Je préfère encore de tester les méthodes privées, mais mon patron est respirer en bas de mon cou sur un produit livrable 🙁

  • L'humour moi, Pourquoi voulez-vous appeler votre constructeur à l'extérieur de votre implémentation de la classe ?
  • Pourquoi le vote serré? C'est encore une question valable, même si il n'est pas recommandé pour obtenir le constructeur.
  • D'accord-encore une question, pourquoi fermer?
  • Re: Essai des méthodes privées. J'ai trouvé que par des essais privés méthodes individuellement, mes tests sont plus petits et plus précis que si je ne tester que les méthodes publiques. J'ai tendance à faire de "privé" en "protégés" et écrivez un gestionnaire spécifique de la classe dans la bibliothèque de test pour les exposer comme des versions publiques plutôt que d'utiliser la réflexion.
  • Herbi, Votre classe plus de chances d'avoir quelques odeurs de code si vos méthodes de test obtenir de gros pour être en mesure de tester privé/protégé méthodes.
  • Oui, beaucoup de l'héritage du code écrit par d'anciens développeurs. De Plus, je dois dire que l'entreprise en cause la logique (la partie échange de chiffre d'affaires) est ridiculement compliqué (plus complexe que mon Doctorat pour un début), mais c'est la façon dont nos clients.
  • Je ne peux imaginer une raison pour un privé ctor. Ok, objet de la piscine de modèle et d'obtenir de l'instance, mais même là, je le ferais protégé. Donc, est-il une raison pour un privé ctor à tous?

InformationsquelleAutor AndrewJacksonZA | 2010-11-12
  1. 44

    Constructeurs par défaut sont privés pour une raison. Le développeur n'est pas privé pour le plaisir.

    Mais si vous voulez continuer à utiliser le constructeur par défaut que vous obtenez par l'aide de la réflexion.

    var constructor = typeof(Bob).GetConstructor(BindingFlags.NonPublic|BindingFlags.Instance, null, new Type[0], null);
var instance = (Bob)constructor.Invoke(null);

    Modifier

    J'ai vu votre commentaire sur le test. Ne jamais tester protected ou private méthodes /propriétés. Vous avez probablement fait quelque chose de mal si vous ne pouvez pas gérer à tester ces méthodes/propriétés par le biais de l'API publique. Soit de les supprimer ou de refactoriser la classe.

    Edit 2

    Oublié une liaison drapeau.

    • N'est-ce pas une sorte de hack? Pour contourner la raison, le constructeur privé?
    • Oui, il est. C'est pourquoi j'ai écrit constructeurs par Défaut sont privés pour une raison. Le développeur n'est pas privé pour le plaisir.
    • Merci. Cependant, la GetConstructor méthode renvoie la valeur nulle, de sorte que le code renvoie une exception NullReferenceException. typeof(Bob).GetConstructors(BindingFlags.NonPublic); renvoie un tableau vide.
    • Essayez de nouveau avec le code mis à jour. Je l'ai juste testé moi-même et ça fonctionne.
    • M. - Oui, c'est clairement un hack, mais c'est exactement ce que l'OP demande dans sa question, de sorte que rend ce la bonne réponse 😉
    • Je vous remercie.
    • "ne jamais tester protected ou private méthodes" - Si le code que vous recherchez n'est PAS en cours de test, alors vous avez certainement devraient place des tests autour privé et protégé méthodes AVANT de commencer refactoring pour les rendre obsolètes... Si ce n'est pas en cours de test, puis son pas refactoring.. sa changeant juste de la merde
    • Si vous ne pouvez pas obtenir une bonne couverture de code dans le privé par le biais des méthodes de test les méthodes publiques que vous avez mort de code qui doit être supprimé.
    • Je ne suis pas sûr à ce sujet le commentaire "ne jamais tester les méthodes privées". Alors que je suis généralement d'accord, que si il veut se MOQUER de cette classe de test dans l'isolement d'un objet qui utilise une instance de cette classe? Il est préférable de maintenir la méthode de privé, car elle est créée par un utilitaire méthode statique, mais veut s'en moquer. Ou, plus facilement, l'api est mal écrit, mais que vous voulez toujours avoir des tests pour votre code dealong avec l'api, j'ai eu une situation comme ça
    • J'ai trouvé cela très utile pour mes besoins, j'ai donc envie de donner un argument en faveur d'où il est est approprié hacky réflexion comme ceci: enfermé dans le sous-sol d'une très bien testé, bibliothque. Cette astuce m'a permis d'utiliser des objets immuables avec EntityFramework par derrière-le-scènes de la transformation de o => new MyImmutableObject(o.Name, o.Description) à o => new MyImmutableObject() { o.Name, o.Description}, sans avoir à sacrifier l'immuabilité ailleurs (le constructeur par défaut est "privé"). Merci à vous pour mettre en garde contre elle, mais je vous remercie doublement pour répondre à toute façon.
    • J' en désaccord à propos de ne pas tester les méthodes privées. Ici est une situation dans laquelle je pense que c'est approprié. Supposons que vous ayez un constructeur qui prend un tableau. Il appelle une fonction privée dans une boucle à chaque élément de la matrice. Je ne voudrais pas faire de la privé de la fonction publique juste pour le tester.
    • J'ai écrit qu'il y a cinq ans. Cependant, dans votre cas, une autre solution est de ne pas avoir que dans un constructeur (ou une méthode privée), mais dans une nouvelle catégorie qui génère le résultat que la catégorie souhaitez travailler. Mon point est que chaque fois que vous avez une méthode privée qui ne peut être atteint facilement, vous pourriez avoir à repenser la conception de votre. Les méthodes privées qu'il est difficile de test est un potentiel d'odeur et doit toujours être évaluée une deuxième fois.
    • Je me retrouve souvent à l'aide de la réflexion sur les constructeurs privés et les champs afin de se moquer des classes qui sont fortement liés à l'électricité statique des instances d'autres classes. Dans legacy code que vous avez souvent cant appliquer injection de dépendance partout, donc vous devez fournir les dépendances d'une certaine façon. Faire cela via la réflexion pour éviter le réel instanciation de la dépendance avec une grande chance de réussir est hacky mais de se débarrasser de ces dépendances pour le test-fins.
    • souvent, vous voulez aussi ajouter BindingFlags.Public pour obtenir de l'ctor
    • Dans ce cas, il était sur les constructeurs privés. D'où la Non publiques drapeau.

    InformationsquelleAutor jgauffin
  2. 2

    Il y a plusieurs façons de contourner ce problème:

    Un: Faire le constructeur public. Si vous avez besoin d'y accéder à partir de l'extérieur de la classe pourquoi est-il privé (c'est peut être que vous ne voulez accéder au constructeur privé pour le test, dans lequel cas, c'est une question valable).

    Deux: Faire le constructeur protégé, l'accès au travers d'une classe dérivée:

    public class Bob
{
    public String Surname { get; set; }

    protected Bob()
    { }

    public Bob(string surname)
    {
        Surname = surname;
    }
}

public class Fred : Bob
{
    public Fred()
        : base()
    {
    }
}

    Trois: Utiliser la réflexion (comme indiqué par jgauffin).

    • Comme vous pouvez le voir dans le modifier sur la question, c'est pour le test, merci. Et la mise en forme est toujours dehors.
    • la mise en forme du code des bugs lors de l'utilisation de listes dans la même réponse.
    • Cheers -- je vais l'essayer et n'oubliez pas que pour l'avenir.
    InformationsquelleAutor Dr Herbie
  3. 2

    En plus de @jgauffin la réponse qui raconte comment appeler les constructeurs privés via la réflexion:

    Est-il possible de changer les paramètres du constructeur privé?

    Il me semble que vous êtes la mise en œuvre de l'Usine de Modèle dans votre code. Ainsi, le modificateur est censé être internal.

    public class Product
{
   //others can't create instances directly outside the assembly
   internal Product() { }    
}
public class ProductProvider
{
   //they can only get standardized products by the provider
   //while you have full control to Product class inside ProductProvider
   public static Product CreateProduct()
   {
       Product p = new Product();    
       //standardize the product
       return p;
   }  
}

    Les méthodes d'Extension

    public static MyExt
{
   public static void DoSomething(this Product p) { }
}

    Appel p.DoSomething() en fait égal à MyExt.DoSomething(p). Ce n'est pas cette méthode dans la classe Produit.

    • Juste une remarque - le modificateur d'accès "interne" n'est pas une restriction à l'espace de noms, mais au niveau de l'assemblage. voir :msdn.microsoft.com/en-us/library/7c5ka91b.aspx. Yoou pourrait également placer la statique de l'usine de méthode dans la classe du Produit lui-même.
    InformationsquelleAutor Cheng Chen
  4. 0

    Vous pouvez instancier les instances de ce type par la réflexion.

    InformationsquelleAutor Frederik Gheysels
  5. 0

    La méthode Bobby est toujours dans une classe différente, appelé Fred. C'est pourquoi vous ne pouvez pas accéder à la prive constructeur de la Bob de classe. Ce que vous essayez de faire n'est pas possible avec joint méthodes. Même si ils peuvent être fixés sur une autre classe, ils sont encore déclarée en dehors de la classe et suivent le champ d'application/les règles d'accès.

    • Merci pour vos commentaires. J'ai inclus Bobby montrer ce que j'ai fait en sorte que personne ne perd leur temps, ce qui suggère des méthodes d'extension.
    InformationsquelleAutor Liviu M.
  6. 0

    Si vous êtes en utilisant dotnet core, vous pouvez effectuer les opérations suivantes sans même avoir à jouer avec toute la réflexion:

    YourCustomObject player = (YourCustomObject)Activator.CreateInstance(typeof(YourCustomObject),true);
    InformationsquelleAutor DenLilleMand
  7. -1
    public class demo
{
   private demo()
    {
        Console.WriteLine("This is no parameter private constructor");
    }
    public demo(int a)
    {
        demo d = new demo('c');//u can call both private contstructors from here
        demo dd = new demo();
        Console.WriteLine("This is one parameter public constructor");
    }
    private demo(char a)
    {
        Console.WriteLine("This is one parameter public constructor::" + a);
    }
}

class Program
{
    static void Main(string[] args)
    {
        demo obj = new demo(7);
        //demo obj = new demo();  //it will raise error
        Console.ReadLine();
    }
}
    • S'il vous plaît commentaire votre solution
    InformationsquelleAutor G Ravi