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. |
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/ |
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. > |
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? |
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 |
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 |
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. |
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. > > > > > > > > |
Free forum by Nabble | Edit this page |