-
When we create a class: put it in its own file
-
entry point: the first line exexuted in the code
-
If you don't need to change data in your file:
attr_reader
only. Can always go back and change to access
*JSON: program agnostic(allows you to use in most languages), data stores in hashes and strings, human-readable,
inheritance
specialization of super class. Share data with another class
class Student
attr_reader :name, :email, :phone
def inititalize(student)
@name = student["name"]
@email = student["email"]
@phone = student["phone"]
end
end
require('./student.rb')
require 'json'
json = FILE.read("students.json")
data - JSON.parse(json)
student_list = []
#where we initialize
data.each do |student|
student_list << Student.new(student)
end
flag = ARGV[0]
number = ARGV[1].to_i
if ('-g' == flag)
student_list.shuffle.each_slice(number) do |groups|
groups.each { |student|
puts student.name
}
end
elsif ('-n' == flag)
student_list.sample(number).each do |student|
p student.name
end
else
p "Error: please select a flag option: -g or -n"
end
-
the more you think about what you want to build, the less time you spend while you are coding
-
often, build "bare bones" model, get it to function, then make it extendable
-
main relationship for design: "has a" or "is a" => (inheritance)
-
How do we take real world things that are happening and make it into a template for a model?
**scenario: You own a building. You need to write a software program that manages the rentals for us.
-
Domain: Apartment, apartment rentals, building
-
Requirement:
- tenant information
- track rental availability
- rental description
- payment information
- request for repair repairs
- rental assignements
- complaints
- Tenant
- Unit
- Building
Building:
@address
@units
-list_available_units
-annual_income
-total_sqft_rented
-contact_list
Unit:
@tenant
@number
@sqft
@bed
@bath
@rent
-occupied? (occupied_on)
Tenant:
@name
@email
@phone
@lease_end
Relationship: Building HAS Unit (1..n)/ Unit HAS Building (1) Unit HAS Tenant (0..1)/Tenant HAS Unit (1)
- High Arching Overview
- sample testing
Test Driven Development
TDD Test first, then code
- name after file you're testing
- stack trace- has a counter and prints to the screen
- assume that it needs a class
.should
a method. Almost all rspecs will have this method--color
return passed tests in green and failed in red