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

Question

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

public IUserFactory
{
    User CreateNewUser();
}

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

Вот перевод той же проблемы на 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 4

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

Answer 5

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

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

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