Another banking question...wow..weird

[jfq722]

Obviously, I've been away from class designing for a while ;)

Trying to shake the rust off by designing a little system to hold my financial info. I intend to do this the right way (with UML), but I can't resist peeking ahead a little bit. And of course if I get hung up while peeking ahead, I have to have it resolved ;(

I'm a little hung up here:

At some point ACCOUNT (holding maybe owner name(s), account number, & open() close() methods etc... should be a abstract base class. This seems obvious, but is it just as obvious to say that, well, all accounts have the possibility of TRANSACTIONS. (which could including a bare minimum of date, description & amount).

So if we agree that:

ACCOUNT
-------
methods:
open();
close();

data:
m_owner;
m_nbr;
list<TRANSACTION> m_activity;


As I'm thinking that INVESTMENT_ACCOUNT can derive from ACCOUNT, but how to work in the idea that the transactions for INVESTMENT_ACCOUNT will need to also have info like: "shares transacted" or "share price".

Now I don't like the idea of force fitting it and saying that even TRANSACTION should contain "share price", just have it be $1.00.

Possibly use this in Account:

list<TRANSACTION*> m_activity;

And the CTOR of INVESTMENT_ACCOUNT can populate the list with allocated INVESTMENT_TRANSACTIONs which would derive from TRANSACTION and add on share_price & nbr_of_shares_transacted?.

[jsmith]

That's one way.

Is it therefore safe to say that only INVESTMENT_ACCOUNTs have INVESTMENT_TRANSACTIONs? ie, there is a tight coupling?

You can use type erasure to solve the problem of the declaration of m_activity.
Type erasure, with example code, is explained here: http://www.artima.com/cppsource/type_erasure.html