How do you use Intefaces with the Factory Pattern in Domain-Driven Design?

Question

Does it make sense to use interfaces for your domain object factories by default, or should interfaces be reserved for the factory classes only when you need them?

public IUserFactory
{
    User CreateNewUser();
}

public UserFactory : IUserFactory
{
    public User CreateNewUser()
    {
        return new User();
    }
}

Answer 1

Not everything has to have an interface; if you have a single implementation of something, and no reason to have any other I can't see why define an interface.

Answer 2

Creating the factory off an interface allows it much easier to test them with mock classes, as well as making it simpler to use IoC applications, so whilst I may not necessarily need them for the application functionality, I generally build and call most classes through interfaces.

If you are not considering Unit Tests or IoC patterns (religious opinions aside), I probably wouldn't bother.

I find the biggest pain with using them, in Visual Studio at least, is that 'Go To Definition' on a property or function jumps to the Interface definition, not the class definition.

Answer 3

Two things: (1) I'd wait until I needed (or saw a looming need) an alternative implementation before I'd create the interface and (2) interfaces almost always make unit testing easier, especially with mocking, so I frequently come up with a need for an interface right away.

Answer 4

In your given example, I don't even see why you need to go Factory.

The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses." - Wikipedia

Do you have a different type of Users, or User is itself a type of something. May be you didn't elaborate the thing clearly. We usually use interface in abstract factory method pattern, where we need to deal with multiple families of related objects.

NOTE: Don't forget, patterns are there to help us, it doesn't mean that we must use them because they are available, whether we need them or not.

Answer 5

Here's a translation of the same problem into Java.

Original example

public interface UserFactoryIF
{
   User createNewUser();
}

Then the implementation of the Factory

public class UserFactory implements UserFactoryIF
{
     public User createNewUser()
     {
         // whatever special logic it takes to make a User
         // below is simplification
         return new User();
     }
}

I don't see any special benefit to defining an interface for the factory, since you're defining a single interface for a centralized producer. Typically I find that I need to produce many different implementations of the same kind of product, and my factory needs to consume many different kinds of parameters. That is, we might have:

public interface User
{
    public String getName();
    public long getId();
    public long getUUID();
    // more biz methods on the User
}

The factory would look like this:

public class UserFactory {

    public static User createUserFrom(Person person) {
        // ...
        return new UserImpl( ... );
    }

    public static user createUserFrom(AmazonUser amazonUser) {
         // ... special logic for AmazonWS user
        return new UserImpl( ... );          
    }

    private static class UserImpl implements User {
       // encapsulated impl with validation semantics to
       // insure no one else in the production code can impl
       // this naively with side effects
    }
}

Hope this gets the point across.