I am working on implementing some stock order types for a financial technology application. There are six different types of stock orders - market, limit, stop_loss, stop_loss_limit, trailing_stop, and trailing_stop_limit. These orders share a minimal subset of properties like IsBuyOrder and TimeInForce. However, they each add their own unique properties as well. For example, stop_price is only relevant to stop_loss and stop_loss_limit order types, and trailing_stop_amount is only relevant to trailing_stop and trailing_stop_limit orders.
As I see it, there are two implementations I can choose from to implement this.
- I can have one relatively large order class with a lot of nullable properties. This class would exposes all of the fields of all the various order types. Many of these fields would be null as they might not apply to the specific type of order that is being created. The advantage of this solution is it's shorter than #2 below, the disadvantage is the class isn't as easy for consumers to understand and utilize.
- I can have an abstract base class called Order which contains the properties common to all order types, and have six child classes implementing the specific order types. The advantage of this solution is it's more clear to the consumer of the class what properties they must set in order to get their order filled. The disadvantage is this solution is quite long as I will have seven different classes.
Is #2 better than #1? Is it better to have a large inheritance hierarchy or a single object with lots of null fields? Just looking for some guidance here...