Navigation:  Tutorials > Creating a GUI Application > Designing the Domain Models >

PersonalMoney

Previous pageReturn to chapter overviewNext page

The PersonalMoney class can be subclassed from Model. This will usually be the norm for domain model classes that are liable to trigger update events when aspects of them change. You might choose a different superclass if you need to inherit specific behaviour from another class or if your model does not trigger any update events (in this latter case a more suitable superclass might be Object). Define the PersonalMoney class as follows:

Model subclass: #PersonalMoney

instanceVariableNames: 'owner accounts '

classVariableNames: ''

poolDictionaries: ''

 

The owner instance variable will hold a string containing the user's name, and the account variable will hold a collection of account objects.

The next responsibility is to add any specialized instance creation methods that the class may require. We have two instance variables here that require initialization and the normal method to ensure that this occurs is to add an initialize instance method to the class and arrange that this is called from whenever an instance is created. In fact, the Model superclass contains a new method that sends #initialize to all newly created instances, therefore we only need to add the initialize functionality since it will be called by default.

initialize

       "Private - Initialize the receiver"

       accounts := ListModel new.

 

We initialize our accounts collection with a ListModel rather than just an OrderedCollection because we'll want to receive change notifications as the list is updated. If this was not the case then a plain OrderedCollection would do just fine.

The next step is to add Accessor Methods to allow other objects access to the contents of the instance variables.

owner

       "Answer the owner of the receiver"

       ^owner.

 

owner: aString

       "Set the owner of the receiver to aString"

       owner := aString.

 

accounts

       "Answer the accounts collection"

       ^accounts

 

There is no need to add an accessor method to set the accounts collection since this is only ever necessary during the initialization of an instance. Consequently this can be considered a private operation which does not warrant such a method.

The next duty, according to the New Class pattern, is to define the class’s behaviour. A useful method to add to all new classes is #printOn: to print the contents of an object in a form suitable for a developer to read. This will aid later testing and debugging.

printOn: aStream

       "Append, to aStream, a String whose characters are a description of the

       receiver as a developer would want to see it."

 

       self basicPrintOn: aStream.

       aStream nextPut: $(.

       self owner printOn: aStream.

       aStream nextPut: $).

 

We are also going to need to add new PersonalAccounts to the application and also to allow them to be removed.

addAccount: aPersonalAccount

       "Add aPersonalAccount to the collection of accounts owned by the

       receiver Answers aPersonalAccount"

 

       ^self accounts add: aPersonalAccount

 

removeAccount: aPersonalAccount

       "Remove aPersonalAccount from the collection of accounts owned by the

       receiver. Answers aPersonalAccount"

 

       ^self accounts remove: aPersonalAccount

 

Notice the use of descriptive parameter names for these methods which aids readability.