Должны ли фабрики устанавливать свойства модели?

В рамках общего SOLID усилия программирования я создал интерфейс factory и абстрактный factory в базовом API-интерфейсе.

Люди уже начинают перегружать фабрики Create method. Проблема в том, что люди перегружают метод Create с помощью свойств модели (и тем самым ожидают, что factory заполнит их).

По-моему, настройка свойств не должна выполняться с помощью factory. Я не прав?

public interface IFactory
{
    I Create<C, I>();
    I Create<C, I>(long id); //<--- I feel doing this is incorrect

    IFactoryTransformer Transformer { get; }
    IFactoryDataAccessor DataAccessor { get; }
    IFactoryValidator Validator { get; }
}

ОБНОВЛЕНИЕ. Для тех, кто не знаком с принципами SOLID, вот несколько из них:

Принцип единой ответственности
В нем говорится, что каждый объект должен иметь одну ответственность и что ответственность должна быть полностью инкапсулирована классом

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

Принцип инверсии зависимостей
В нем говорится, что вы должны разделить свои программные модули. Чтобы достичь этого, вам нужно изолировать зависимости.

В целом:
Я на 90% уверен, что знаю ответ. Тем не менее, я бы хотел, чтобы хорошие обсуждения у людей, уже использующих SOLID. Спасибо за ваши ценные мнения.

ОБНОВЛЕНИЕ. Итак, что я должен сделать, чтобы SOLID factory должен был делать?

IMHO sOLID factory обслуживает соответствующие объекты-экземпляры... но делает это таким образом, который скрывает сложность создания объекта. Например, если у вас есть модель Employee... вы бы попросили factory предоставить вам подходящую. DataAccessorFactory предоставит вам правильный объект доступа к данным, ValidatorFactory предоставит вам правильный объект проверки и т.д.

Например:

var employee = Factory.Create<ExxonMobilEmployee, IEmployee>();
var dataAccessorLdap = Factory.DataAccessor.Create<LDAP, IEmployee>();
var dataAccessorSqlServer = Factory.DataAccessor.Create<SqlServer, IEmployee>();
var validator = Factory.Validator.Create<ExxonMobilEmployee, IEmployee>();

Взяв пример далее, мы бы...

var audit = new Framework.Audit(); // Or have the factory hand it to you
var result = new Framework.Result(); // Or have the factory hand it to you

// Save your AuditInfo
audit.username = 'prisonerzero';

// Get from LDAP (example only)
employee.Id = 10;
result = dataAccessorLdap.Get(employee, audit);
employee = result.Instance; // All operations use the same Result object

// Update model    
employee.FirstName = 'Scooby'
employee.LastName = 'Doo'

// Validate
result = validator.Validate(employee);

// Save to SQL
if(result.HasErrors)
     dataAccessorSqlServer.Add(employee, audit);

ОБНОВЛЕНИЕ - Так почему я категорически против этого разделения?

Я чувствую, что разделяющие обязанности делают для меньших объектов, меньшие Unit Tests и повышают надежность и обслуживание. Я признаю, что он делает это за счет создания большего количества объектов... но это то, что защищает меня SOLID factory... он скрывает сложность сбора и создания экземпляров указанных объектов.

Ответы

var model = this.factory.Create();
model.Id = 10;
model.Name = "X20";

var employee = Factory.Create<ExxonMobilEmployee, IEmployee>();