Hi Joseph,

I don't know what you want to model. Assuming the accounts already exist, you can attach each transaction to the account. But then you would need a collection of accounts somewhere.

In that case each account will have a collection of transactions. OTOH if you need your transactions to replay them all on a 'database' (like Smalltalk's changes file or the transaction log of a rdbms) it's useful to have a second collection where you also put the transactions in.

Basically if you have many of anything you put them in a collection and use the powerful collection protocol do deal with them.

Sorry for being so vague but I hope to get the message :-))

Cheers

Herbert

Greetings,

I have several Accounts and the accounts have Transactions.

On 10/16/12 13:53, Joseph J Alotta wrote:

Greetings,

I have several Accounts and the accounts have Transactions.

My plan was to instantiate a Transaction and to populate it from a file, and then have each of the Transactions attach themselves to an Account.

This is a sort of bottom up design.

The problem is that I have a bunch of Accounts and Transactions running around the system and no tools for working with them.

I can do Accounts allInstances do: []. But then I also get old instances (from debugging).

Is this a good way of doing things? Do I need to have some Collection somewhere, so I can go and find each item when I need it? Like a common control mechanism? And if so, what would it look like?

Do you think I should create a list of accounts and then each Account will have a list of Transactions? The old top down approach?

Sincerely,

Joe.

I read through the other responses...maybe one of them already answered your question. The only thing I could think to add is...

Normally when you're reading Transactions from a file you have some way of identifying which transactions are associated with with accounts. This takes the form of an account id and is either part of the transaction file's name or it is give in each transaction record in that file. One simple thing to is use that account id as a key in a Dictionary for looking up the associated accounts:

"I assume that somewhere you have a list of accounts...here's some stand-in code for creating a dictionary from that list" accounts := Dictionary new. accounts at: 1 put: (Account new id: 1; owner: 'Fred Smith'; yourself). accounts at: 2 put: (Account new id: 2; owner: 'Sally Jones'; yourself).

"Now we read the transaction, I'll assume each transaction knows its #accountId" rs := ....read stream on your file... [rs atEnd] whileFalse: [|t| t := Transaction readFromStream: rs. (accounts at: t accountId) addTransaction t].

Hope that helps.

David

On 16/10/12 1:53 PM, Joseph J Alotta wrote:

I have several Accounts and the accounts have Transactions.

Then your abstract model is:

[Account] <--->> [Transaction]

(i.e. one-to-many)

My plan was to instantiate a Transaction and to populate it from a file, and then have each of the Transactions attach themselves to an Account.

Is this bootstrapping some objects/data into your prototype, or is it what how you ultimately want to operate?

The problem is that I have a bunch of Accounts and Transactions running around the system and no tools for working with them.

I can do Accounts allInstances do: []. But then I also get old instances (from debugging).

Is this a good way of doing things?

Probably not, for the reasons you give.

Do I need to have some Collection somewhere, so I can go and find each item when I need it? Like a common control mechanism? And if so, what would it look like?

You probably want a collection. A common place is a class variable on the model object (e.g. Account and/or Transaction).

You only need it if you want to be able to search for a model, based on the models attributes. For example, if you never have to locate a Transaction by its transaction numbers, then you don't need a collection to hold them all. You'll have to locate the transaction by first locating the account object.

Do you think I should create a list of accounts and then each Account will have a list of Transactions? The old top down approach?

Don't know what is meant by top down approach, but in this case I think you want a list of accounts and a list of transactions. Each account would have a collection of its transactions, and each transaction might (or might not) hold a reference back to the corresponding account (or an account number, to find the account, via the account list).

Back to the model:

--------------------- | Account | | * account number | | - account balance | ---------------------

--------------------- | Transaction | | * txn number | | - txn amount | ---------------------

In an RDB implementation, you would create a TABLE for each model. In Smalltalk, you would manage an Account list, and maybe a Transaction list as well.

In an RDB, you might introduce a synthetic id (i.e. some sequence number) for each Account and Transaction object. In Smalltalk, you can think of the reference to an Account object held by the Account list as the equivalent of the synthetic id.

In an RDB, you have to introduce an extra referential attribute into the Transaction table to handle the one-to-many relationship. In Smalltalk, you have the choice mentioned earlier. You can keep a list of transactions for each account. If necessary, you can keep a back reference to the account, in each transaction; or, keep just the account number, to allow searching the account list.

Some differences from an RDB implementation are that you can choose the type of collection for the Account list (or Transaction list). They can be dictionaries keyed by account number (or by txn number), for example. You don't have to maintain a Transaction list, like you have to create a Transaction TABLE. You can navigate directly to an Account's transactions, rather than having to do a JOIN in an RDB.