Bibliothèque Wrapper - Builder vs Factory avec POCO

Question

Je suis coincé entre un rock et un endroit difficile en ce moment essayant de décider d'une bonne mise en page API pour un projet .NET COM wrapper sur lequel je travaille. C'est principalement un problème de conception et ce qui fonctionnerait mieux.

J'ai donc cet objet point COM:

public class COMPoint 
{ 
    internal COMPoint(MyComObject comobject) {} 
    public SomeCollection Nodes {get; set;} 
} 

maintenant afin de faire objet point dans mon objet COM que je dois appeler quelques commandes de chaîne, et c'est là que je vais avoir du mal à décider où pour le montrer.

Maintenant, j'ai pensé à utiliser un POCO qui a des propriétés dessus, puis passez-le dans une sorte de méthode d'usine, quelque chose comme ça;

public class Point 
{ 
    public SomeCollection Nodes {get;set;} 
} 

public class GeometryFactory 
{ 
    public GeometryFactory(MyComObject comobject) {} 
    public CreateCOMPointFrom(Point point) 
    { 
     // Do COM work here and return new COMPoint. 
    } 
} 

ou en utilisant un modèle de constructeur, quelque chose comme:

public class COMPoint 
{ 
    internal COMPoint(MyComObject comobject) {} 
    public SomeCollection Nodes {get; set;} 

    public class Builder 
    { 
     public Builder(MyComObject comobject) {} 
     public SomeCollection Nodes {get; set;} 
     public COMPoint Create() 
     { 
     // Do COM work here and return new COMPoint. 
     } 
    } 
} 

ou une combinaison des deux:

public class COMPoint 
{ 
    internal COMPoint(MyComObject comobject) {} 
    public SomeCollection Nodes {get; set;} 

    public class Builder 
    { 
     public Builder(MyComObject comobject) {} 
     public SomeCollection Nodes {get; set;} 
     public COMPoint Create() 
     { 
     // Do COM work here and return new COMPoint. 
     } 

     public COMPoint CreateFrom(Point point) 
     { 
     // Set builder properties and call. 
     this.Create(); 
     } 
    } 
} 

L'idée derrière l'aide d'un POCO était que les gens puissent créer un point objet utilisant le bon vieux

Point point = new Point() 
point.Nodes <- Set nodes 

passez-le autour de leur code, puis construisez-le et récupérez celui qui retourne à l'objet COM.

Pensez-vous que l'un de ces modèles a du crédit dans cette situation? Je suis inquiet que si j'ai deux objets ponctuels différents, cela pourrait troubler l'utilisateur, mais là encore, le modèle du constructeur n'est pas vraiment sympa non plus, hmm ce qu'il faut faire.

Bien sûr, l'objet ponctuel est l'objet le plus simple que j'ai à créer, il y a beaucoup plus d'objets qui sont un peu plus compliqués.

Merci.

Answer 1

Je crois que vous pouvez combiner les modèles Builder et Factory, puis vous pouvez appliquer le "Unify interfaces with Adapter" dans Refactoring Pattern livre. S'il vous plaît, corrigez-moi si je me trompe de direction. Comme vous l'avez mentionné, vous allez créer des objets différents complexes basés sur le point (?).

Vous pouvez créer AbstractBuilder en tant que générateur de niveau supérieur, chaque sous-classe de AbstractBuilder sera responsable de la création d'objets complexes avec une interface commune (peut être l'interface COMPoint). Ensuite, vous pouvez appliquer le modèle Factory pour créer un objet à partir de la sous-classe AbstractBuilder. Chaque objet ponctuel peut être une interface COMPoint ou un objet adaptateur qui implémente une interface differnet si vous utilisez un objet différent à créer.

J'espère que ça aide.