Designing an Order service that accepts many types of orders

Question

I've been having some trouble coming up with a design that would alleviate most, if not all, the issues I've been running into, and I'm wondering if it is my base design.

Our company accepts orders. We accept different types of orders based on the product line they belong to, but all orders share some functionality and properties. My goal is to inject any order implementing a specific interface into a OrderRepository class.

In order to fulfill these needs, I created an OrderBase class:

public class OrderBase {
    public string order_number {get; set;}
    public string order_type {get; set;}
    public string order_date {get; set;}
    public List<IOrderItem> order_items { get; set; }
    public virtual bool Validate();
}

I created an interface that mimics the base class so I can utilize the base class as exactly that... the base functionality for an order.

public interface IOrder {
    string order_number {get; set;}
    string order_type {get; set;}
    string order_date {get; set;}
    List<IOrderItem> order_items { get; set; }
    bool Validate();
}

One type of order is implemented as such:

public class TXOrder : OrderBase, IOrder {

    // Specific to TXOrder only
    public bool isOnHold {get; set; }

    public override bool Validate() {
        // Enter TXOrder-specific validations here.
        return base.Validate();
    }
}

TXOrder inherits the base class, getting all those properties and methods and the implemented interface is fulfilled by the base class properties and methods. This works well right now with ModelBinders that map to the correct object per the data coming in.

The repository looks like this:

interface IRepository<T, U>
        where U : IParameters
    {
        T SelectSingle(long id);
        List<T> Select(U parameters);
        T Insert(T entity);
        T Update(T entity);
        T Delete(T entity);
    }

public  class OrderRepository: IRepository<IOrder, OrderParameters> {}

If you need the gory details of the OrderRepository, don't hesitate to ask. It accepts any order I throw at it of type IOrder. That's the key point to take away.

Is this a pattern that can continue to work long-term as I add specific functionality for each order type? Is there another pattern I can look at?

Answer 1

I think you should stop using the base class and the order type and just go with interfaces. I would define interfaces that represent the various characteristics that orders can have, and implement the interfaces that make sense for each order type. In this way your logic is based on a set of properties and methods being available rather than an order type value.

For example if you defined interfaces like this

public interface IOrder
{
    Int OrderId { get; set; }
    DateTime OrderDate { get; set; }
}

public interface IValidatable
{
    void Validate();
}

public interface IDiscountable
{
    void Discount();
}

Then you can create different order types like this

public class OrderA: IOrder, IValidatable
{ ... etc ... }

public class OrderB: IOrder, IDiscountable
{ ... etc ... }

public class OrderC: IOrder
{ ... etc ... }

When you pass an IOrder into your order manager rather than having logic based on order type, you can base your logic on the whether the order implements a specific interface, for example

public void Process(IOrder order)
{
    var validatable = order as IValidatable;
    If (validatable != null)
        validatable.Validate();

    var discountable = order as IDiscountable;
    if (discountable != null)
        discountable.Discount();
}

Answer 2

I think you don't need interface at all.
If OrderBase class used only as container of basic functionality, then make it abstract

public abstract class OrderBase 
{
    public virtual string order_number {get; set;}
    public virtual string order_type {get; set;}
    public virtual string order_date {get; set;}
    public virtual List<IOrderItem> order_items { get; set; }
    public virtual bool Validate();
}

And derived class will inherit only abstract class without interface.

If you want keep interfaces and basic logic, then make base class implement interface

public class OrderBase : IOrder
{
    public string order_number {get; set;}
    public string order_type {get; set;}
    public string order_date {get; set;}
    public List<IOrderItem> order_items { get; set; }
    public virtual bool Validate();
}

Specific class will inherit only from base class

public class TXOrder : OrderBase
{
    public bool isOnHold {get; set; }

    public override bool Validate() 
    {
        // Specific validation
    }
}

But remember that when you pass different types of order to the "handler" method as basic class or interface, then you will not have access to the specific properties or methods.

You can use them only through method you override.

public override bool Validate() 
{
    if(isOnHold == true) return false;
}

This approach will work until you will need somehow to get access to the specific properties or methods by consumer of orders.