Conception de classe: constructeur public ou privé avec usine statique et un objet COM

Question

Je suis un peu un problème de conception de classe. Je vais décrire les trois modèles que je considère.

Exemple 1:

Class MyObject 
{ 
    public MyObject(IWrapper wrapper,string name) 
    {//set properties.} 

    public Void Declare() 
    { 
     //Some COM stuff with IWrapper 
    } 
} 

utilisation:

MyObject testobj = new MyObject(fakewrapper,"test"); 
testobj.Declare(); 

Exemple 2:

Class MyObject 
{ 
    public MyObject(IWrapper wrapper,string name) 
    { //set properties.} 

    public MyObject Declare() 
    { 
     //Some COM stuff with IWrapper 
     return this; 
    } 
} 

Utilisation:

MyObject testobj = new MyObject(fakewrapper,"Test"); 
testobj = testobj.Declare(); 

Exemple 3: Utilisation de constructeur privé

Class MyObject 
{ 
    private MyObject(IWrapper wrapper,string name) 
    {//set properties.} 

    public static MyObject Declare(IWrapper wrapper,string name) 
    { 
     //Some COM stuff with IWrapper 
     return new MyObject(wrapper,name); 
    } 
} 

Utilisation:

MyObject testobj = MyObject.Declare(fakewrapper,"Test"); 

Mes principales questions sont; Selon vous, quel est le meilleur design?
Est-ce une mauvaise pratique de masquer le constructeur en faveur d'une méthode d'usine statique? J'essaie aussi de rendre ceci aussi testable que possible. La seule raison pour laquelle je n'arrive pas à me décider est que la classe MyObject est un wrapper autour d'un autre objet dans une application COM.

Le problème est que cet objet doit être déclaré dans l'application COM qui est ce que le déclare méthode fait avant toute autre méthode peut être appelée, mais si je cache le constructeur, puis ajouter plus de travail à la Declare méthode Je pense que cela rendra le reste de la classe difficile à tester, car je dois d'abord passer par la méthode Declare.

Cheers.

Answer 1

L'option 3 me semble être l'API la plus propre pour votre classe. Si vous ne pouvez pas vraiment utiliser MyObject jusqu'à ce que Declare soit appelé, pour moi, il serait logique d'intégrer le nouveau et Declare dans une méthode usine, pour s'assurer que les utilisateurs de votre classe n'essaient pas d'utiliser MyObject sans d'abord appeler Declare. Les méthodes d'usine peuvent également aider avec l'entretien sur la route. Une façon d'aider avec la testabilité pourrait être d'encapsuler l'opération Declare dans une interface "IDeclarer" enfichable dans la classe. Votre application de production utiliserait une implémentation de IDeclarer qui appelle l'application COM, alors que votre code de test pourrait brancher un IDeclarer simulé. Peut-être quelque chose comme ça (vous aurez probablement à tordre cela ...):

class MyObject 
{ 
    public IDeclarer Declarer { get; set; } 

    private MyObject(IWrapper wrapper,string name) 
    { 
     // set properties 
    } 

    public static MyObject Declare(IWrapper wrapper,string name) 
    { 
     //Some COM stuff with IWrapper 
     MyObject newMyObject = new MyObject(wrapper,name); 
     return Declarer.Declare(newMyObject); 
    } 
} 

public interface IDeclarer 
{ 
    MyObject Declare(MyObject obj); 
} 

public class ComDeclarer : IDeclarer 
{ 
    public MyObject Declare(MyObject obj) 
    { 
     // do COM work 
     return comObj; 
    } 
} 

public class TestDeclarer : IDeclarer 
{ 
    public MyObject Declare(MyObject obj) 
    { 
     // do nothing... or whatever 
     return testObj; 
    } 
}