views:

85

answers:

4

Hello, I have to program some financial applications where I have to represent a schedule of flows. The flows can be of 3 types:

  • fee flow (just a lump payment at some date)
  • floating rate flow (the flow is dependant of an interest rate to be determined at a later date)
  • fixed rate flow (the flow is dependant of an interest rate determined when the deal is done)

I need to keep the whole information and I need to represent a schedule of these flows. Originally I wanted to use inheritance and create three classes FeeFlow, FloatingFlow, FixedFlow all inheriting from ICashFlow and implement some method GetFlowType() returning an enum then I could dynamic_cast the object to the correct type.

That would allow me to have only one vector<IFlow> to represent my schedule.

What do you think of this design, should I rather use three vectors vector<FeeFlow>, vector<FloatingFlow> and vector<FixedFlow> to avoid the dynamic casts ?

+8  A: 

Why do you actually need the dynamic casts? Make your flow subclasses implement the same interface polymorphically, then there is no need to cast anything.

If they need very different inputs, you could try passing the different inputs as constructor parameters, thus clearing up the common interface. However, if you really can't define a common interface for them, maybe they are better implemented as independent classes.

Péter Török
+1  A: 

If all the operations you need to do with the different types of the flow differ only by the underlying data, i would suggest extending the ICashFlow with such operations - then no dynamic casting is needed. If however this is not possible, then both options are ok i think. I personally would choose the one with the three vectors, if there is no other hidden need for one vector of base classes.

PeterK
A: 

I think the strategy pattern would suit you best.

You implement a CashFlow class that contains a CashFlowStrategy property which does the processing.

I do not fully understand the requirements and the differences between the flows but something like this might work (meta-c++, not valid code):

class CashFlowStrategy {
  public:
    virtual void ProcessFlow(Account from, Account to);
}

class FixedRateCashFlowStrategy : public CashFlowStrategy {
  public:
    void ProcessFlow(Account from, Account to) { ... }
}

class CashFlow {
  private:
    CashFlowStrategy strategy;
  public:
    CashFlow(CashFlowStrategy &strategy) { this->strategy = strategy; }
    void Process() { this->strategy->ProcessFlow(this->from, this->to); }
}

You only need the std::vector<CashFlow>, the decision of how to do the processing is hidden in the strategy so you shouldn't have to care about it.

dbemerlin
How is this advantageous over just having a virtual function in a CashFlow base class or interface? I think this just overcomplicates things. YAGNI.
Alex B
A: 

It sounds like you have various schedules and various types of deposits, which collectively make up a financial flow. The solution sounds as if a strategy pattern may work for both schedule and deposit behavior. Although, if you have room, it might be worth considering a functional approach. A lambda expression would give you the same logic with a tenth of the code ...

NoelAdy