Klassenentwurf: öffentlicher Konstruktor oder privat mit statischer Factory und einem COM-Objekt

Question

Ich habe ein kleines bisschen ein Klassenentwurfsproblem. Ich werde die drei Muster skizzieren, die ich in Betracht ziehe.

Beispiel 1:

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

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

Verwenden:

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

Beispiel 2:

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

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

Verwenden:

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

Beispiel 3: Verwendung von privaten Konstruktor

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); 
    } 
} 

Verwendung:

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

Meine Hauptfragen sind; Welches ist deiner Meinung nach das bessere Design?
Ist es eine schlechte Übung, den Konstruktor zugunsten einer statischen Factory-Methode zu verbergen?

Ich versuche auch, dies so überprüfbar wie möglich zu machen. Der einzige Grund, warum ich mich nicht entscheiden kann, ist, dass die MyObject-Klasse ein Wrapper um ein anderes Objekt in einer COM-Anwendung ist.

Das Problem ist, dass dieses Objekt in der COM-Anwendung deklariert werden muss, das ist es, was die erklärt Methode wird vor jedem anderen Verfahren zu tun aufgerufen werden kann, aber wenn ich den Konstruktor verstecken und dann mehr Arbeit zu den Declare hinzufügen Methode Ich denke, es wird den Rest der Klasse schwer zu testen, weil ich zuerst die Declare-Methode durchlaufen muss.

Prost.

Answer 1

Option 3 scheint mir die sauberste API für Ihre Klasse zu sein. Wenn Sie MyObject nicht wirklich verwenden können, bis Declare aufgerufen wird, wäre es für mich sinnvoll, das neue und Declare in eine Factory-Methode zu verpacken, um sicherzustellen, dass Benutzer Ihrer Klasse nicht versuchen, MyObject zu verwenden, ohne zuerst Declare aufzurufen. Factory-Methoden können auch bei der Wartung auf der Straße helfen.

Eine Möglichkeit, die Testbarkeit zu unterstützen, besteht möglicherweise darin, die Declare-Operation in eine steckbare "IDeclarer" -Schnittstelle in der Klasse zu integrieren. Ihre Produktionsanwendung würde eine Implementierung von IDeclarer verwenden, die die COM-App aufruft, während Ihr Testcode einen falschen IDeclarer einbinden könnte. Vielleicht so etwas (Sie müssen das wahrscheinlich noch ändern ...):

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; 
    } 
}