Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hotel.rb #24

Open
wants to merge 46 commits into
base: master
Choose a base branch
from
Open

hotel.rb #24

wants to merge 46 commits into from

Conversation

kayxn23
Copy link

@kayxn23 kayxn23 commented Sep 10, 2018

Hotel

Congratulations! You're submitting your assignment!

Comprehension Questions

Question Answer
Describe a design decision you had to make when working on this project. What options were you considering? What helped you make your final decision? In the beginning I had to decide if certain behaviors should belong to either Room, Reservation or TrackingSystem classes. I considered creating more behaviors in the Reservation class, but eventually decided to write them in the TS class to so that I could centralize all the behaviors, and because it makes more sense for a TrackingSystem to have behaviors than Room and Reservation objects in real life.
Describe a concept that you gained more clarity on as you worked on this assignment. I gained more clarity on composition by trial and error. I realize more how mapping out has-a and is-a relationships prior to coding is crucial part of the design process, because each object needs to work together and ideally be flexible for change. Also, I learned that it's difficult to decipher User Stories, and I need to ask more clarification questions around this.
Describe a nominal test that you wrote for this assignment. Making sure that the methods throw errors if an invalid argument is entered is in most of my tests.
Describe an edge case test that you wrote for this assignment. Making sure that an argument error is raised if a start_date is after an end_date input.
How do you feel you did in writing pseudocode first, then writing the tests and then the code? I was able to follow this procedure more than half of the time writing this program. Writing pseudocode comes more naturally than writing tests, but I think this project has made me more comfortable than before with driving my code with Tests. It's difficult to write tests for a method that is more complex and when I'm not sure how it's going to look yet. Writing tests did help guide my code, but I kept getting drawn into writing the code methods when errors came up. I need more practice coming up with edge cases.

…servatoin method in TrackingSystem class, tests passing but still need to refactor for more reasonable usability
…refactoring this code and creating helper methods"
…ssertions, 2 failures(failures surrounding create reservation )
…. now the method returns an array of available rooms
… rather than Array. Each reservation just stores one room
… commented out code blocks in TrackingSystem to see if I'll call on that method from TS later
@CheezItMan
Copy link

Hotel

What We're Looking For

Feature Feedback
Baseline
Used git regularly Good number of commits and good commit messages
Answer comprehension questions Check, I hope you see now that you probably should have broken out some functionality into Reservation and Block
Design
Each class is responsible for a single piece of the program You have TrackingSystem doing too much. Pretty much all your code is going there and Reservation and Block are pretty much just structs.
Classes are loosely coupled Yes
Wave 1
List rooms Check
Reserve a room for a given date range Check
List reservations for a given date Check
Calculate reservation price Check
Invalid date range produces an error Check, but that check should go in Block and Reservation
Test coverage 99%
Wave 2
View available rooms for a given date range Check
Reserving a room that is not available produces an error Check
Wave 3
Create a block of rooms Check
Check if a block has rooms Check
Reserve a room from a block Check
Fundamentals
Names variables, classes and modules appropriately Check
Understanding of variable scope - local vs instance Check
Can create complex logical structures utilizing variables Check
Appropriately uses methods to break down tasks into smaller simpler tasks Your methods could use some breaking down and your classes are too centralized.
Understands the differences between class and instance methods Check
Appropriately uses iterators and enumerables You mostly just used .each.
Appropriately writes and utilizes classes Like I've said you centralized too much in TrackingSystem.
Appropriately utilizes modules as a mechanism to encapsulate functionality No modules
Wrap Up
There is a refactors.txt file Check
The file provides a roadmap to future changes Check
Additional Feedback Nice work. You hit all the learning goals. I do think your design is a bit awkward as too much is done in TrackingSystem, but it all works. I also left some small comments in your testing. Overall outstanding work.

class Reservation
attr_reader :room_num, :start_time, :end_time, :price

def initialize(attributes)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should have some checks to make sure the start and end dates are correct here.

total_cost = 0
return total_cost = ((end_time - start_time) * price).round(2)
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to add methods to tell if two reservations clash, or if a reservation is on a specific date.

require_relative 'block'
require 'pry'

NUMBER_OF_ROOMS = 20

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good use of constants!

raise ArgumentError.new"#{date} must be instance of Date" unless date.instance_of? Date
all_reservations = []
@reservations.each do |reservation|
if (reservation.start_time...reservation.end_time).include?(date)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would make a great deal of sense to have a method in Reservation to tell if the reservation occurs on the given date. That way the tracking system doesn't need to involve itself in the internal details of a reservation.

available_rooms << room
else
room.reserved_dates.each do |dates_hash|
if ranges_overlap?((dates_hash[:start_time]...dates_hash[:end_time]).to_a, (start_time..end_time).to_a) == false && room.block == :NA

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because a room's reservation range doesn't overlap once, doesn't mean the room isn't reserved on that date.

end

it "raises an ArgumentError if no reservations are available on given date" do
expect{@tracker.view_reservations_on(Date.new(3333,10,5))}.must_raise ArgumentError

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why raise an error, why not just return an empty list?

expect(@available_rooms[0]).must_be_kind_of Room
end

it "raises ArgumentError if no rooms are available on these dates(aka they're in a block or reserved)" do

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test assumes too much detail about how Room is implemented. Instead what you could do is add 20 reservations on a given date using TrackingSystem' s method. Then try making a 21st reservation on the same date range.

@reservations = @tracker.add_reservation(start_time: Date.new(2018,8,1), end_time: Date.new(2018,8,25), number_of_rooms:1)
@reservations = @tracker.add_reservation(start_time: Date.new(2018,8,1), end_time: Date.new(2018,8,25), number_of_rooms:6)
list = @tracker.reservations
expect(@reservations).must_be_kind_of Array

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more testing reservations instead of add_reservation

it "raises ArgumentError if there are not enough available-rooms on the requested date" do
expect{@tracker.add_reservation(start_time: Date.new(2018,1,1),end_time:Date.new(2018,1,2),number_of_rooms:350)}.must_raise ArgumentError
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should also test that if you make 2 reservations in the same date range, they are for different rooms.

Also test that you can make a reservation on the same date as another reservation ends.

end
end

describe "#retrieve_block_dates" do

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest using a block Id number instead of a symbol just because it's easier to work with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants