Help with Class Design

Question

I have a class that has to take product information from one system's database and save it to another system's product database.

I'll call a product from the first system Product A and the other Product B. Product B's data depends on settings selected from a user.

So Product B may have a GetDescriptions method that looks at a user setting that says use Description1 variable from Product A or they could select Description 2 or they could use the Description already in Product B.

This is fine, but there are a lot of settings and ways to get description. This is the problem, I have a lot of methods that all seem to pertain to Product B. Methods like GetDescription, GetName, GetSku, that are all set according to user settings and all depend on Product A.

Although they all seem to relate to Product B, the class is growing very large and I want to move some of the methods out of the class into another class. I was thinking about using the Factory pattern. Something like below (code just a quick idea)

public class ProductBuilder
{
    public ProductB BuildProduct()
    {
          SkuBuilder.BuildSku(ProductB,ProductA);
          ProductDescriptionBuilder.BuildDescription(ProductB,ProductA);
    }
}

My questions are: What is a good design for this? Is the method I've proposed above acceptable? Do you see any potential problems with this design?

Answer 1

I would make the suggestion to work with abstraction in your ProductBuilder instead directly with ProductA and ProductB ... This way you can change implementation painless later. Use Interface or abstract class ...

Also it will be easier for testing and mocking.

Answer 2

This is a variation on the factory pattern, and it's a very useful form of design. What you've written suggests a neat three-class design: ProductA containing methods and properties only pertaining to A, ProductB with methods and properties pertaining to B, and ProductBuilder which builds you a B based on an A.

The only pitfalls of this are general OOP design issues. Make sure that ProductConverter doesn't depend on internal knowledge of A or B--in other words, make sure that the public interface to A and B is rich enough for the ProductConverter to do its job. Only A should connect to A's product database and only B should connect to B's product database. Avoid singletons and global state. These are things that you'd do in almost any application, but they'll be special traps in this kind of system.