design issue of someone trying to think like a smalltaker

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

design issue of someone trying to think like a smalltaker

Joseph Alotta
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.








Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

Chris Cunnington
On 12-10-16 1:53 PM, 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.
>
>

Keeping things in the image and accessing them with #allInstances is a
bit raw. It's conventional to use a Collection. And, you pull things in
from files with Streams. Squeak By Example [1] can help here. Chapter 9
for the Collections and Chapter 10 for Streams.

Chris


[1] http://squeakbyexample.org/

Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

Herbert König
In reply to this post by Joseph Alotta
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

Bob Arning-2
In reply to this post by Joseph Alotta
You certainly will, one way or the other, sooner or later. ;-) Either an account will live in the image, which means some other object keeps a reference to the account so it does not get garbage collected, or it lives in a database somewhere and you read it in when needed. For starting to explore, the list of accounts in the image will be the easiest thing to do. If you mess things up real bad, then something like
    MasterAccountList := OrderedCollection new.
gives you a new beginning.

Cheers,
Bob

On 10/16/12 1:53 PM, Joseph J Alotta wrote:
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?



Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

cdavidshaffer
In reply to this post by Joseph Alotta
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



Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

cdavidshaffer
On 10/16/12 15:48, C. David Shaffer wrote:
> (accounts at: t accountId) addTransaction t].

that should have been...

... addTransaction: t].

dropped the colon :-)

David


Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

Yanni Chiu
In reply to this post by Joseph Alotta
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.

Reply | Threaded
Open this post in threaded view
|

Re: design issue of someone trying to think like a smalltaker

Chris Muller-3
In reply to this post by Joseph Alotta
Hi Joseph, my sense is that you are asking about how to _separate_
Account instances you created in the past from newer versions of
Accounts based on having made further progress in your development.

You mentioned that allInstances do: [] gives you old instances from
debugging, which you don't want.

My solution to this partitioning -- e.g.,to  keep only the instances
of Accounts which belong together separate from old instances of
Accounts which I'm no longer interested in because they're defunct
because I was just debuggin them -- is to use the "World" pattern.

It's actually a published pattern TMK but, in this case, the World
could be called "AccountsBook" or something like that.  It would have
(at least) two inst-vars called "accounts" and "transactions".

Now, you have a place to put methods ("tools" or otherwise) to operate
on just the related groups of Accounts and Transactions.

This is what I do for all my models now -- the World object ends up
being the root object of the database and the root of the entire
model.

 - Chris


On Tue, Oct 16, 2012 at 12:53 PM, Joseph J Alotta
<[hidden email]> 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.
>
>
>
>
>
>
>
>