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

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

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

Answer 3

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

Если вы не рассматриваете модульные тесты или образцы IoC (религиозные мнения в стороне), я, вероятно, не стал бы беспокоиться.

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

Answer 4

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

Answer 5

В данном примере я даже не вижу, почему вам нужно идти на завод.

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

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

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