我对显式强制转换运算符的使用是否合理？

我有一个大对象：

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

还有一个专门的，类似于DTO的对象：

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

我个人发现了将BigObject显式转换为SmallObject的概念-知道这是一种单向丢失数据的操作-非常直观且易读：

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

它使用显式运算符实现：

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

现在，我可以SmallObjectFactory使用FromBigObject(BigObject big)方法创建一个类，该类将执行相同的操作，将其添加到依赖项注入中，并在需要时调用它……但是对我来说，这似乎更加复杂和不必要。

PS我不确定这是否相关，但是将可以OtherBigObject将其转换为SmallObject，并设置为different EnumType。

在我的拙见中，没有其他答案是对的。在这个stackoverflow问题中，投票最高的答案认为映射代码应放在域之外。要回答您的问题，不-您对强制转换运算符的使用不是很好。我建议您做一个映射服务，该服务位于您的DTO和您的域对象之间，或者您可以为此使用automapper。

太好了 我使用的代码巧妙地完成了这一工作，并导致了混乱。毕竟，你会希望能够只分配BigObject到一个SmallObject变量，如果对象是相关的，足以扮演他们。但是，它不起作用-如果尝试进行编译，则会出现编译器错误，因为就类型系统而言，它们是无关紧要的。对于铸造操作人员来说，制造新物体也令人反感。

我会推荐一种.ToSmallObject()方法。关于实际发生的事情和冗长的内容，我们会更加清楚。

虽然我可以看到您为什么需要使用SmallObject，但是我会以不同的方式处理该问题。我处理此类问题的方法是使用Facade。其唯一目的是封装BigObject并仅提供特定成员。这样，它是同一实例上的新接口，而不是副本。当然，你可能还需要执行复制，但我会建议您通过对组合的目的与门面（例如创建了一个方法，这样做return new SmallObject(instance.Clone())）。

Facade具有许多其他优点，即确保程序的某些部分只能使用通过Facade提供的成员，从而有效地保证了它无法利用不应了解的内容。除此之外，它还有一个巨大的优势，那就是您可以BigObject在将来的维护中更灵活地进行更改，而不必担心在整个程序中如何使用它。只要您可以某种形式模仿旧的行为，就可以SmallObject像以前一样进行工作，而不必在BigObject将要使用的所有地方更改程序。

请注意，这BigObject并不取决于SmallObject而是相反（正如我的拙见）。

有一个非常严格的约定，对可变引用类型的强制转换是保留身份的。因为在将源类型的对象分配给目标类型的引用的情况下，系统通常不允许用户定义的强制转换运算符，所以只有少数情况下用户定义的强制转换操作对于可变引用是合理的类型。

我建议作为一个要求，x=(SomeType)foo;稍后再加上y=(SomeType)foo;，两个强制转换都应用于同一对象x.Equals(y)，即使该对象在两个强制转换之间进行了修改，也应该永远永远正确。如果例如一个对象具有一对不同类型的对象，每个对象持有另一个对象的不可变引用，并且将一个对象转换为另一种类型将返回其配对实例，则可能会出现这种情况。它也可以与用作可变对象包装器的类型一起使用，前提是被包装的对象的标识是不可变的，并且如果两个相同类型的包装器包装相同的集合，它们将报告自己相等。

您的特定示例使用了可变的类，但没有保留任何形式的身份。因此，我建议这不是铸造操作员的适当用法。

可能没关系。

您的示例存在一个问题，就是您使用了类似示例的名称。考虑：

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

现在，当你有个好主意什么长和int的含义时，intto 的隐式转换long和from的显式long转换int都是可以理解的。这也是可以理解如何3成为3和只是另一种方式与工作3。这是可以理解的，这int.MaxValue + 1在检查的上下文中将如何失败是可以理解的。即使int.MaxValue + 1在不受约束的情况下如何实现结果int.MinValue也不是最难的事情。

同样，当您隐式转换为基本类型或显式转换为派生类型时，任何知道继承如何工作，发生什么情况以及结果将是什么（或失败的方法）的人都可以理解。

现在，对于BigObject和SmallObject，我对这种关系的工作方式一无所知。如果您的实类型使得转换关系明显，那么转换可能确实是一个好主意，尽管在很多时候，也许是绝大多数，如果是这种情况，那么它应该反映在类层次结构和普通的基于继承的转换就足够了。