# Confused: instances or arrays? **URL:** \ **Category:** Ruby\ **Created:** [October 6, 2010, 4:34am UTC](https://www.ruby-forum.com/t/confused-instances-or-arrays/196056 "2010-10-06T04:34:46Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![prichard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/90db22/32.png) [@prichard](https://www.ruby-forum.com/u/prichard)\ **Post date:** [October 6, 2010, 4:34am UTC](https://www.ruby-forum.com/t/confused-instances-or-arrays/196056/1 "2010-10-06T04:34:46Z")
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? ---
**Author:** ![prichard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/90db22/32.png) [@prichard](https://www.ruby-forum.com/u/prichard)\ **Post date:** [October 6, 2010, 6:52am UTC](https://www.ruby-forum.com/t/confused-instances-or-arrays/196056/2 "2010-10-06T06:52:46Z")
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 ---
**Author:** ![prichard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/90db22/32.png) [@prichard](https://www.ruby-forum.com/u/prichard)\ **Post date:** [October 6, 2010, 9:53am UTC](https://www.ruby-forum.com/t/confused-instances-or-arrays/196056/3 "2010-10-06T09:53:01Z")
On Wed, Oct 6, 2010 at 6:52 AM, Jeremy B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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: > **[Object composition](https://en.wikipedia.org/wiki/Object_composition)** > > In computer science, object composition and object aggregation are closely related ways to combine objects or data types into more complex ones. In conversation the distinction between composition and aggregation is often ignored. Common kinds of compositions are objects used in object-oriented programming, tagged unions, sets, sequences, and various graph structures. Object compositions relate to, but are not the same as, data structures. > Object composition refers to the logical or concept... 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. 🙂 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: > **[Class-responsibility-collaboration card](https://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card)** > > Class-responsibility-collaboration (CRC) cards are a brainstorming tool used in the design of object-oriented software. They were originally proposed by Ward Cunningham and Kent Beck as a teaching tool but are also popular among expert designers and recommended by extreme programming practitioners. Author Martin Fowler has written that CRC cards may be a sensible means by which multiple alternative interactions may be quickly devised, as they avoid a great deal of drawing and erasing. CR CRC 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. 🙂 Kind regards robert