Pros and cons of 'new' properties in C# / .Net?

Question

Considering the following sample code:

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

and the following sample Order class:

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

When i derive a new type of order class, it will inherit the Delivery property of type DeliveryStrategy.

Now, when it is given that CustomerOrders must be delivered using the ParcelDelivery strategy, we could consider 'new'ing the Delivery property in the CustomerOrder class:

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

(The CustomerOrder obviously needs to ensure that is compatible (polymorph) with Order)

This allows direct usage of the ParcelDelivery strategy on CustomerOrder without the need for casting.

Would you consider using this pattern? why / why not?

Update: i came up with this pattern, instead of using generics, because i want to use this for multiple properties. I don't want to use generic type arguments for all these properties

Answer 1

I'd prefer to make the type generic:

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

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

This ensures type safety at compile-time, rather than leaving it up to execution time. It also prevents the situation of:

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

ParcelDelivery delivery = customerOrder.Delivery; // Returns null

Ouch.

I regard new as usually a last resort. It introduces added complexity both in terms of implementation and use.

If you don't want to go down the generic route, I'd introduce a genuinely new property (with a different name).

Answer 2

I think this is a good pattern. It makes it easier to explicitly use derived types by removing the need to cast the result, and it doesn't 'break' the base class behavior. Actually, a similar pattern is used in some classes in the BCL, for instance look at the DbConnection class hierarchy :

• DbConnection.CreateCommand() returns a DbCommand
• SqlConnection.CreateCommand() hides the base implementation using 'new' to return a SqlCommand.
• (other DbConnection implementations do the same)

So, if you manipulate the connection object through a DbConnection variable, CreateCommand will return a DbCommand ; if you manipulate it through a SqlConnection variable, CreateCommand will return a SqlCommand, avoiding the cast if you're assigning it to a SqlCommand variable.