Felipe Maion
Felipe Maion

Reputation: 351

Ruby: Hash, Arrays and Objects for storage information

I am learning Ruby, reading few books, tutorials, foruns and so one... so, I am brand new to this. I am trying to develop a stock system so I can learn doing. My questions are the following:

I created the following to store transactions: (just few parts of the code)

transactions.push type: "BUY", date: Date.strptime(date.to_s, '%d/%m/%Y'), quantity: quantity, price: price.to_money(:BRL), fees: fees.to_money(:BRL)

And one colleague here suggested to create a Transaction class to store this. So, for the next storage information that I had, I did:

@dividends_from_stock << DividendsFromStock.new(row["Approved"], row["Value"], row["Type"], row["Last Day With"], row["Payment Day"])

Now, FIRST question: which way is better? Hash in Array or Object in Array? And why?

This @dividends_from_stock is returned by the method 'dividends'.

I want to find all the dividends that were paid above a specific date:

puts ciel3.dividends.find_all {|dividend| Date.parse(dividend.last_day_with) >  Date.parse('12/05/2014')}

I get the following:

#<DividendsFromStock:0x2785e60>
#<DividendsFromStock:0x2785410>
#<DividendsFromStock:0x2784a68>
#<DividendsFromStock:0x27840c0>
#<DividendsFromStock:0x1ec91f8>
#<DividendsFromStock:0x2797ce0>
#<DividendsFromStock:0x2797338>
#<DividendsFromStock:0x2796990>

Ok with this I am able to spot (I think) all the objects that has date higher than the 12/05/2014. But (SECOND question) how can I get the information regarding the 'value' (or other information) stored inside the objects?

Upvotes: 0

Views: 488

Answers (3)

Felipe Maion
Felipe Maion

Reputation: 351

thank you!

I will answer my question, based on the information provided by tadman and Ilya Vassilevsky (and also B. Seven).

1- It is better to create a class, and the objects. It will help me organize my code, and debug. Localize who is who and doing what. Also seems better to use with DB.

2- I am a little bit shamed with my question after figure out the solution. It is far simpler than I was thinking. Just needed two steps:

willpay =  ciel3.dividends.find_all {|dividend| Date.parse(dividend.last_day_with) >  Date.parse('10/09/2015')}

willpay.each do |dividend| 
puts "#{ciel3.code} has approved #{dividend.type} on #{dividend.approved} and will pay by #{dividend.payment_day} the value of #{dividend.value.format} per share, for those that had the asset on #{dividend.last_day_with}"
puts
end

Upvotes: 0

Ilya Vassilevsky
Ilya Vassilevsky

Reputation: 1001

  1. Generally it is always better to define classes. Classes have names. They will help you understand what is going on when your program gets big. You can always see the class of each variable like this: var.class. If you use hashes everywhere, you will be confused because these calls will always return Hash. But if you define classes for things, you will see your class names.
  2. Define methods in your classes that return the information you need. If you define a method called to_s, Ruby will call it behind the scenes on the object when you print it or use it in an interpolation (puts "Some #{var} here").

Upvotes: 1

tadman
tadman

Reputation: 211740

You probably want a first-class model of some kind to represent the concept of a trade/transaction and a list of transactions that serves as a ledger.

I'd advise steering closer to a database for this instead of manipulating toy objects in memory. Sequel can be a pretty simple ORM if used minimally, but ActiveRecord is often a lot more beginner friendly and has fewer sharp edges.

Using naked hashes or arrays is good for prototyping and seeing if something works in principle. Beyond that it's important to give things proper classes so you can relate them properly and start to refine how these things fit together.

I'd even start with TransactionHistory being a class derived from Array where you get all that functionality for free, then can go and add on custom things as necessary.

For example, you have a pretty gnarly interface to DividendsFromStock which could be cleaned up by having that format of row be accepted to the initialize function as-is.

Don't forget to write a to_s or inspect method for any custom classes you want to be able to print or have a look at. These are usually super simple to write and come in very handy when debugging.

Upvotes: 1

Related Questions