typeparam - summary c# visual studio

¿Deberían las fábricas establecer las propiedades del modelo?

Question

Como parte de un esfuerzo global de programación S.O.L.I.D. , creé una interfaz de fábrica y una fábrica abstracta dentro de una API de marco base.

La gente ya está empezando a sobrecargar las fábricas. Crear método. El problema es que las personas están sobrecargando el método Crear con las propiedades del modelo (y por lo tanto esperan que la fábrica las rellene).

En mi opinión, la configuración de la propiedad no debe ser realizada por la fábrica. ¿Me equivoco?

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

ACTUALIZACIÓN - Para aquellos que no están familiarizados con los principios de SOLID, aquí hay algunos de ellos:

Principio de Responsabilidad Única
Establece que cada objeto debe tener una responsabilidad única, y que la responsabilidad debe estar completamente encapsulada por la clase

Principio Abierto / Cerrado
El significado de este principio es que cuando se necesita una solicitud para una característica que debe agregarse a su aplicación, debe poder manejarlo sin modificar las clases antiguas, solo agregando subclases y nuevas implementaciones.

Principio de inversión de dependencia
Dice que debes desacoplar tus módulos de software. Para lograrlo necesitarías aislar dependencias.

En general:
Estoy 90% seguro de que sé la respuesta. Sin embargo, me gustaría una buena discusión de personas que ya usan SOLID. Gracias por sus valiosas opiniones.

ACTUALIZACIÓN - Entonces, ¿qué creo que debería hacer una fábrica SÓLIDA?

En mi humilde opinión, una fábrica SÓLIDA ofrece instancias de objetos adecuadas ... pero lo hace de una manera que oculta la complejidad de la creación de instancias de objetos. Por ejemplo, si tiene un modelo de empleado ... le pediría a la fábrica que le consiga el modelo adecuado. El DataAccessorFactory le daría el objeto de acceso a datos correcto, el ValidatorFactory le daría el objeto de validación correcto, etc.

Por ejemplo:

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>();

Tomando el ejemplo más lejos, nosotros ...

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);

ACTUALIZACIÓN - Entonces, ¿por qué estoy convencido de esta separación?

Siento que las responsabilidades de segregación se traducen en objetos más pequeños, pruebas unitarias más pequeñas y mejora la fiabilidad y el mantenimiento. Reconozco que lo hace a costa de crear más objetos ... pero eso es de lo que SOLID Factory me protege ... oculta la complejidad de reunir e instanciar dichos objetos.

Answer 1

Después de aproximadamente 6 meses de experiencia en inyección de dependencia, solo descubrí algunos casos en los que las fábricas deberían establecer propiedades:

1. Si el configurador está marcado como internal , y se espera que las propiedades se establezcan solo una vez por la fábrica. Esto generalmente ocurre en interfaces con solo get propiedades cuyas implementaciones se espera que se creen a través de una fábrica.

2. Cuando el modelo utiliza propiedades de inyección. Rara vez veo clases que usan la inyección de propiedades (también trato de evitar construirlas), pero cuando veo una, y el servicio necesario solo está disponible en otros lugares, es un caso en el que no tiene otra opción.

Para el resultado final, deje public set ajustes public set fuera de las fábricas. Solo establezca las propiedades que están marcadas como internal Permita que los clientes decidan qué propiedades necesitan establecer si se les permite hacerlo. Esto mantendrá sus fábricas limpias de funciones innecesarias.

Answer 2

Suponiendo que su interfaz de fábrica se usa desde el código de la aplicación (a diferencia de la raíz de composición de infraestructura), en realidad representa un Localizador de servicios, que puede considerarse un antipatrón con respecto a la inyección de dependencia. Véase también Localizador de servicios: roles frente a mecánicos .

Tenga en cuenta que el código como el siguiente:

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

Es solo la sintaxis del azúcar. No elimina la dependencia de la implementación concreta de ExxonMobilEmployee .

Es posible que también le interesen los canales de mensajes de tipo débil frente a los de tipo fuerte y el despacho de mensajes sin ubicación de servicio (que ilustran cómo dichas interfaces violan el SRP ) y otras publicaciones de Mark Seemann.

Answer 3

Yo diría que se adhiere al principio DRY , y en la medida en que sea un simple cableado de valores , no lo veo como un problema / violación. En vez de tener

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

dispersos por todo el código base, casi siempre es mejor tenerlo en un solo lugar. Los cambios futuros de contratos, refactorizaciones o nuevos requisitos serán mucho más fáciles de manejar.

Vale la pena señalar que si tal creación de objetos y luego la configuración de propiedades es común , ese es un patrón que su equipo ha evolucionado y los desarrolladores que agregan sobrecargas son solo una respuesta a este hecho (en particular, uno bueno). Lo que se debe hacer es introducir una API para simplificar este proceso.

Y nuevamente, si se reduce a tareas simples (como en su ejemplo) no dudaría en mantener las sobrecargas, especialmente si es algo que se nota con frecuencia. Cuando las cosas se complican más, sería un signo de nuevos patrones que se están descubriendo y tal vez debería recurrir a otras soluciones estándar (como el patrón del constructor, por ejemplo).