Confused: instances or arrays?

Hi. I want to create the following class…

Client

attributes
name, amount_wealth, loans, lender, bankrupt (a boolean)

methods

is_client_solvent? (I declare the client bankrupt if total amount of
loans is greater than wealth)

amount_owed (amount owed to the lender)

lender_owed (the amount owed to the lender)

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?

Is it correct to use 2 different instance names for client “Joe Bloggs”?
i.e client1 and client2

If I use many instances, how do I get the aggregate of loans of each
bank for a specific client?

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. :slight_smile:

-Jeremy

On Wed, Oct 6, 2010 at 6:52 AM, Jeremy B. [email protected] wrote:

is_client_solvent? (I declare the client bankrupt if total amount of

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.

I’d rather say “object relationships” because that is the more general
concept. “Nesting” sounds like “aggregation” which is already a
specific way to relate objects:
http://en.wikipedia.org/wiki/Object_composition#Aggregation

good explanation

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. :slight_smile:

For this I find the CRC approach quite helpful. It’s simple and
focuses on the main important aspects without distracting the designer
by having too much detail:
http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card

IIRC there are even software tools around for this but I find the
manual paper and pencil approach much better since software tools
usually also have a certain level of distraction built in. :slight_smile:

Kind regards

robert

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs