title: Should factories set model properties?
body: <p>As part of an overall <a href="http://www.codeproject.com/Articles/60845/The-S-O-L-I-D-Object-Oriented-Programming-OOP-Prin" rel="nofollow noreferrer">S.O.L.I.D.</a> programming effort I created a factory interface &amp; an abstract factory within a base framework API.</p>
  
  <p>People are already starting to overload the factories Create method.  The problem is people are overloading the Create method with model properties (and thereby expecting the factory to populate them).</p>
  
  <p><strong>In my opinion, property setting should not be done by the factory.  Am I wrong?</strong></p>
  
  <pre><code>public interface IFactory
  {
      I Create&lt;C, I&gt;();
      I Create&lt;C, I&gt;(long id); //&lt;--- I feel doing this is incorrect
  
      IFactoryTransformer Transformer { get; }
      IFactoryDataAccessor DataAccessor { get; }
      IFactoryValidator Validator { get; }
  }
  </code></pre>
  
  <p><strong>UPDATE - For those unfamiliar with SOLID principles, here are a few of them:</strong><br/></p>
  
  <p><strong>Single Responsibility Principle</strong><br/>
  It states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class</p>
  
  <p><strong>Open/Closed Principle</strong><br/>
  The meaning of this principle is that when a get a request for a feature that needs to be added to your application, you should be able to handle it without modifying old classes, only by adding subclasses and new implementations.</p>
  
  <p><strong>Dependency Inversion Principle</strong><br/>
  It says that you should decouple your software modules. To achieve that you’d need to isolate dependencies. </p>
  
  <p><strong>Overall:</strong><BR/>
  I'm 90% sure I know the answer.  However, I would like some good discussion from people already using SOLID.  Thank you for your valuable opinions.</p>
  
  <p><strong>UPDATE - So what do I think a a SOLID factory should do?</strong><br/></p>
  
  <p>IMHO a SOLID factory serves-up appropriate object-instances...but does so in a manner that hides the complexity of object-instantiation.  For example, if you have an Employee model...you would ask the factory to get you the appropriate one.  The DataAccessorFactory would give you the correct data-access object, the ValidatorFactory would give you the correct validation object etc.</p>
  
  <p>For example:</p>
  
  <pre><code>var employee = Factory.Create&lt;ExxonMobilEmployee, IEmployee&gt;();
  var dataAccessorLdap = Factory.DataAccessor.Create&lt;LDAP, IEmployee&gt;();
  var dataAccessorSqlServer = Factory.DataAccessor.Create&lt;SqlServer, IEmployee&gt;();
  var validator = Factory.Validator.Create&lt;ExxonMobilEmployee, IEmployee&gt;();
  </code></pre>
  
  <p>Taking the example further we would...</p>
  
  <pre><code>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);
  </code></pre>
  
  <p><strong>UPDATE - So why am I adamant about this separation?</strong><br/></p>
  
  <p>I feel segregating responsibilities makes for smaller objects, smaller Unit Tests and it enhances reliability &amp;  maintenance.  I recognize it does so at the cost of creating more objects...but that is what the SOLID Factory protects me from...it hides the complexity of gathering and instantiating said objects.</p>