c# - C#/.Net 中 'new' 属性的优缺点？

Question

考虑以下示例代码:

// delivery strategies
public abstract class DeliveryStrategy { ... }
public class ParcelDelivery : DeliveryStrategy { ... }
public class ShippingContainer : DeliveryStrategy { ... }

和以下示例订单类:

// order (base) class
public abstract class Order
{
    private DeliveryStrategy delivery;

    protected Order(DeliveryStrategy delivery)
    {
        this.delivery = delivery;
    }

    public DeliveryStrategy Delivery
    {
        get { return delivery; }
        protected set { delivery = value; }
    }
}

当我派生一个新类型的订单类时，它将继承 DeliveryStrategy 类型的 Delivery 属性。

现在，如果必须使用 ParcelDelivery 策略交付 CustomerOrders，我们可以考虑在 CustomerOrder 类中“新建”Delivery 属性:

public class CustomerOrder : Order
{
    public CustomerOrder()
        : base(new ParcelDelivery())
    { }

    // 'new' Delivery property
    public new ParcelDelivery Delivery
    {
        get { return base.Delivery as ParcelDelivery; }
        set { base.Delivery = value; }
    }
}

(CustomerOrder 显然需要确保与 Order 兼容(多态))

这允许在 CustomerOrder 上直接使用 ParcelDelivery 策略，而无需转换。

您会考虑使用这种模式吗？为什么/为什么不？

更新:我想出了这个模式，而不是使用泛型，因为我想将它用于多个属性。我不想对所有这些属性使用通用类型参数

Answer 1

我更愿意使类型通用:

public abstract class Order<TDelivery> where TDelivery : Delivery
{
    public TDelivery Delivery { ... }
    ...
}

public class CustomerOrder : Order<ParcelDelivery>
{
    ...
}

这确保了编译时的类型安全，而不是将其留给执行时。它还可以防止以下情况:

CustomerOrder customerOrder = new CustomerOrder();
Order order = customerOrder;
order.Delivery = new NonParcelDelivery(); // Succeeds!

ParcelDelivery delivery = customerOrder.Delivery; // Returns null

哎呀。

我通常将 new 视为最后的手段。它在实现和使用方面都增加了复杂性。

如果您不想走通用路线，我会介绍一个真正的新属性(使用不同的名称)。