¿Es razonable mi uso del operador explícito de casting o es un mal truco?

Tengo un gran objeto:

class BigObject{
    public int Id {get;set;}
    public string FieldA {get;set;}
    // ...
    public string FieldZ {get;set;}
}

y un objeto especializado tipo DTO:

class SmallObject{
    public int Id {get;set;}
    public EnumType Type {get;set;}
    public string FieldC {get;set;}
    public string FieldN {get;set;}
}

Personalmente, encuentro un concepto de convertir explícitamente BigObject en SmallObject, sabiendo que es una operación unidireccional que pierde datos, muy intuitivo y legible:

var small = (SmallObject) bigOne;
passSmallObjectToSomeone(small);

Se implementa utilizando el operador explícito:

public static explicit operator SmallObject(BigObject big){
    return new SmallObject{
        Id = big.Id,
        FieldC = big.FieldC,
        FieldN = big.FieldN,
        EnumType = MyEnum.BigObjectSpecific
    };
}

Ahora, podría crear una SmallObjectFactoryclase con FromBigObject(BigObject big)método, que haría lo mismo, agregarlo a la inyección de dependencia y llamarlo cuando sea necesario ... pero para mí parece aún más complicado e innecesario.

PD: No estoy seguro de si esto es relevante, pero habrá OtherBigObjectque también se podrá convertir en una SmallObjectconfiguración diferente EnumType.

Ninguna de las otras respuestas tiene razón en mi humilde opinión. En esta pregunta de stackoverflow, la respuesta más votada argumenta que el código de mapeo debe mantenerse fuera del dominio. Para responder a su pregunta, no, su uso del operador de transmisión no es excelente. Aconsejaría hacer un servicio de mapeo que se encuentre entre su DTO y su objeto de dominio, o podría usar automapper para eso.

Es ... No genial. He trabajado con código que hizo este truco inteligente y me llevó a la confusión. Después de todo, esperaría poder asignarlo BigObjecta una SmallObjectvariable si los objetos están lo suficientemente relacionados como para lanzarlos. Sin embargo, no funciona: obtienes errores del compilador si lo intentas, ya que, en lo que respecta al sistema de tipos, no están relacionados. También es un poco desagradable para el operador de fundición hacer nuevos objetos.

Recomendaría un .ToSmallObject()método en su lugar. Es más claro lo que realmente está sucediendo y lo que es detallado.

Si bien puedo ver por qué necesitarías tener un SmallObject, abordaría el problema de manera diferente. Mi enfoque para este tipo de problema es usar una Fachada . Su único propósito es encapsular BigObjecty solo poner a disposición miembros específicos. De esta manera, es una nueva interfaz en la misma instancia, y no una copia. Por supuesto, es posible que también desee realizar una copia, pero le recomendaría que lo haga a través de un método creado para ese propósito en combinación con la Fachada (por ejemplo return new SmallObject(instance.Clone())).

Facade tiene una serie de otras ventajas, como asegurar que ciertas secciones de su programa solo puedan hacer uso de los miembros disponibles a través de su fachada, garantizando efectivamente que no puede hacer uso de lo que no debería saber. Además de esto, también tiene la enorme ventaja de que tiene más flexibilidad para cambiar BigObjecten el mantenimiento futuro sin tener que preocuparse demasiado por cómo se usa en todo su programa. Siempre que pueda emular el comportamiento anterior de una forma u otra, puede hacer que el SmallObjecttrabajo sea el mismo que antes sin tener que cambiar su programa en todas partes BigObject.

Tenga en cuenta que esto significa BigObjectque no depende SmallObjectsino al revés (como debería ser en mi humilde opinión).

Existe una convención muy fuerte que establece que los tipos de referencia mutables preservan la identidad. Debido a que el sistema generalmente no permite operadores de conversión definidos por el usuario en situaciones en las que un objeto del tipo de origen podría asignarse a una referencia del tipo de destino, solo hay unos pocos casos en los que las operaciones de conversión definidas por el usuario serían razonables para una referencia mutable tipos.

Sugeriría como un requisito que, dado x=(SomeType)foo;seguido en algún momento posterior y=(SomeType)foo;, con ambos lanzamientos aplicados al mismo objeto, x.Equals(y)debería ser siempre y para siempre verdadero, incluso si el objeto en cuestión fue modificado entre los dos lanzamientos. Tal situación podría aplicarse si, por ejemplo, uno tuviera un par de objetos de diferentes tipos, cada uno de los cuales tenía una referencia inmutable al otro, y lanzar cualquiera de los objetos al otro tipo devolvería su instancia emparejada. También podría aplicarse con tipos que sirven como envoltorios para objetos mutables, siempre que las identidades de los objetos que se envuelvan sean inmutables, y dos envoltorios del mismo tipo se reportarían como iguales si envolvieran la misma colección.

Su ejemplo particular usa clases mutables, pero no conserva ninguna forma de identidad; como tal, sugeriría que no es un uso apropiado de un operador de casting.

Puede estar bien

Un problema con su ejemplo es que usa dichos nombres de ejemplo. Considerar:

SomeMethod(long longNum)
{
  int num = (int)longNum;
  /* ... */

Ahora, cuando tengas una buena idea de lo que significa un largo e int , entonces tanto el lanzamiento implícito de intto longcomo el lanzamiento explícito de longto intson bastante comprensibles. También es comprensible cómo se 3convierte 3y es solo otra forma de trabajar 3. Es comprensible cómo esto fallará int.MaxValue + 1en un contexto comprobado. Incluso cómo funcionará int.MaxValue + 1en un contexto no controlado para dar como resultado int.MinValueno es lo más difícil de asimilar.

Del mismo modo, cuando realiza una conversión implícita a un tipo base o explícitamente a un tipo derivado, es comprensible para cualquiera que sepa cómo funciona la herencia lo que está sucediendo y cuál será el resultado (o cómo podría fallar).

Ahora, con BigObject y SmallObject no tengo idea de cómo funciona esta relación. Si sus tipos reales eran tales que la relación de lanzamiento era obvia, entonces el lanzamiento podría ser una buena idea, aunque muchas veces, tal vez la gran mayoría, si este es el caso, entonces debería reflejarse en la jerarquía de clases y bastará con una transmisión normal basada en la herencia.