[squeak-dev] Re: design issue of someone trying to think like a smalltaker

Yanni Chiu yanni at rogers.com
Tue Oct 16 21:48:33 UTC 2012


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.


More information about the Squeak-dev mailing list