Как вы используете интерфейсы с фабричным шаблоном в доменно-управляемом дизайне?

Question

Имеет ли смысл по умолчанию использовать интерфейсы для фабрик ваших доменных объектов или интерфейсы должны быть зарезервированы для фабричных классов только тогда, когда они вам нужны?

public IUserFactory
{
    User CreateNewUser();
}

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

Answer 1

Вот перевод той же проблемы на Java.

Оригинальный пример

public interface UserFactoryIF
{
   User createNewUser();
}

Тогда реализация Фабрики

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

Я не вижу особого преимущества в определении интерфейса для фабрики, поскольку вы определяете единый интерфейс для централизованного производителя. Обычно я нахожу, что мне нужно произвести много разных реализаций одного и того же вида продукта, и моей фабрике нужно потреблять много разных видов параметров. То есть мы могли бы иметь:

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

Фабрика будет выглядеть так:

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

Надеюсь, это поможет.

Answer 2

В вашем приведенном примере я даже не понимаю, зачем вам идти на Фабрику.

  

Суть фабричного шаблона   " Определить интерфейс для создания   объект, но пусть подклассы   решить, какой класс для создания экземпляра.   Фабричный метод позволяет отложить класс   создание экземпляров для подклассов. " - Википедия

Есть ли у вас другой тип пользователей, или пользователь сам является чем-то типа. Может быть, вы не прояснили вещь ясно. Мы обычно используем interface в шаблоне абстрактного метода фабрики , где нам нужно иметь дело с несколькими семействами связанных объектов.

ПРИМЕЧАНИЕ. Не забывайте, что шаблоны помогают нам, но это не значит, что мы должны их использовать, потому что они доступны, нужны они нам или нет.

Answer 3

Не все должны иметь интерфейс; Если у вас есть одна реализация чего-либо, и нет причин иметь какую-либо другую, я не понимаю, зачем определять интерфейс.

Answer 4

Две вещи: (1) я бы подождал, пока мне не понадобится (или увидел надвигающуюся необходимость) альтернативная реализация, прежде чем я создам интерфейс, и (2) интерфейсы почти всегда делают модульное тестирование легче, особенно с помощью имитации, поэтому У меня часто возникает необходимость в интерфейсе сразу.

Answer 5

Создание фабрики на основе интерфейса позволяет намного проще тестировать их с помощью фиктивных классов, а также упрощает использование приложений IoC, поэтому, хотя они могут и не понадобиться мне для функциональности приложения, я обычно создаю и вызываю большинство классы через интерфейсы.

Если вы не рассматриваете юнит-тесты или шаблоны IoC (кроме религиозных мнений), я бы не стал беспокоиться.

Я считаю, что самая большая проблема с их использованием, по крайней мере в Visual Studio, заключается в том, что «Перейти к определению» для свойства или функции переходит к определению интерфейса, а не к определению класса.