On 10/05/2010 09:34 PM, Paul R. wrote:
loans is greater than wealth)
The is_client_solvent? method is therefore equivalent to the bankrupt
attribute, correct? If so, one of these names can be an alias for the
other:
def my_method
“In my_method”
end
alias :another_name :my_method
another_name # => “In my_method”
In general, there isn’t much need to be strict about attributes vs.
methods in Ruby. From outside a class, all of your attributes will
operate like methods, possibly with a little syntactic sugar available
depending on how you declare them.
amount_owed (amount owed to the lender)
lender_owed (the amount owed to the lender)
As you’ve already discovered, the above part is pretty limiting…
I have a few questions about this…
it’s possible for a client to have more than one lenders. Do I just
create muliple instances eg…
client1 = new Client(“Joe Bloggs”, 50000, 1000, “USA Bank”, nil)
client2 = new Client(“Joe Bloggs”, 50000, 3000, “Chicago Bank”, nil)
or do I use arrays?
That solution won’t scale well (for both code and performance), and
depending on how you implement it, it could lead to wildly unmanageable
code.
Is it correct to use 2 different instance names for client “Joe Bloggs”?
i.e client1 and client2
The definition of “correct” is ultimately up to you and the logic you
need to implement. In other words, there is more than one way to do it.
However, this way would not be advisable either. For instance, how
would you handle a random assortment of a random number of clients read
in from a file at runtime?
If I use many instances, how do I get the aggregate of loans of each
bank for a specific client?
Don’t use many instances per client. Instead, think nested objects.
A client can have many loans as you indicated. The question to ask next
is what are the attributes of a loan? Among various possibilities
including pay schedule, interest rate, and opening principal; you are
likely to be most immediately interested in the lender and the remaining
principal (or amount owed). So a Loan class could be defined to embody
these attributes of a loan. Once you have a Loan class, you can
instantiate that for each loan in your data and give those Loan
instances to instances of your Client class.
Now your Client class needs to be able to represent clients who have
zero or more loans in their names. Such an attribute might simply be
called “loans”. An array would serve nicely to hold all the possible
loans for a Client instance. Given that array, it should be fairly
straightforward to aggregate the total amount owed on various loans on a
per client bases within the is_client_bankrupt? method.
From here, you can see that we have nested Loan objects within Client
objects. Any time you find yourself thinking that an array of nearly
identical items is a solution, you can usually find a way to express
that relationship with object nesting. This will make your code much
more manageable.
I hope I wasn’t too vague here, but I also don’t want to deny you the
chance to derive the details for yourself. 
-Jeremy
