Wrapper library - Builder vs Factory with POCO

Question

I'm stuck between a rock and a hard place at the moment trying to decided on a good API layout for a .NET COM wrapper project I am working on. This is mainly a design problem and what would work better.

So I have this COM point object:

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

now in order to make point object in my COM object I need to call a few string commands, and this is where I'm having trouble deciding where to point this.

Now I thought about using a POCO that has properties on it then pass it into some kind of factory method, something like this;

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

or using a builder pattern, something like:

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

or a combination of both:

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

The idea behind using a POCO was so that people could create a point object using the good old

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

pass it around their code and then construct it and get back the one that goes back to the COM object.

Do you think any of these patterns have any credit in this situation?

I'm worried that if I have two different point objects it might confuse the user but then again the builder pattern isn't really that friendly either hmm what to do.

Of course the point object is the simplest object I have to create, there are a lot more objects that are a bit more complicated.

Thanks.

Answer 1

I believe that you can combine Builder and Factory patterns, and then you can apply the "Unify interfaces with Adapter" in Refactoring Pattern book. Please, correct me if I goes wrong direction. As you mentioned, you are going to create complex different objects based on the Point(?).

You can create AbstractBuilder as a top level builder, each subclass of the AbstractBuilder will be responsible for creating complex objects with a common interface (may be COMPoint interface).

After that, you can apply the Factory pattern to create an object from the subclass AbstractBuilder. Each point object can be COMPoint interface or an adapter object that implements an differnet interface if you uses different object to be created.

I hope it helps.