Sockets - Hana

[hanalways]

Hotel

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
What was a design challenge that you encountered on this project?	I had trouble trying to decide whether or not Room deserved its own class. Since I decided that there was very little behavior to the room class, I instead decided to represent it as an integer and thus left any representation of it within the reservations class.
What was a design decision you made that changed over time over the project?	Whether or not I wanted to separate occupied rooms away from a list of occupied rooms (and same with available rooms/list of available rooms). By fully fleshing out the responsibilities of each method I was able to use the list methods to be helper methods.
What was a concept you gained clarity on, or a learning that you'd like to share?	How to put wrappers around methods and functions to decrease dependency and increase readability and how to call those methods across classes.
What is an example of a nominal test that you wrote for this assignment? What makes it a nominal case?	A nominal test I wrote for this assignment was to create a single reservation using the reserve_room method and that it returns the instance of the reservation that it made from within the HotelSystem class.
What is an example of an edge case test that you wrote for this assignment? What makes it an edge case?	I wrote a test to make sure that the end_date could not be the same as the start_date for my Reservation class, and would expect to raise an error. This makes it an edge case because it is a case that may happen in real life, and the code handles this case explictly and intentionally.
How do you feel you did in writing pseudocode first, then writing the tests and then the code?	I like the idea and definitely referenced my notes/psuedocode a lot. However, I did feel as if I was a lot more stubborn in letting design ideas go and exploring other ways of accomplishing the features that were set in front of me. Often when refactoring my code I would forget to write tests for the code I wrote and in my zeal of getting code that works, forgot about red-green coding.

[droberts-sea]

Hotel

What We're Looking For

Feature	Feedback
Baseline
Used git regularly	yes
Answer comprehension questions	yes
Design
Each class is responsible for a single piece of the program	yes - I love this two-class design, it is straightforward and clear, without being too simple to address the problem. Good work.
Classes are loosely coupled	yes
Wave 1
List rooms	yes
Reserve a room for a given date range	yes
List reservations for a given date	yes
Calculate reservation price	yes
Invalid date range produces an error	yes
Test coverage	yes
Wave 2
View available rooms for a given date range	yes
Reserving a room that is not available produces an error	yes
Test coverage	yes
Wave 3
Create a block of rooms	N/A
Check if a block has rooms	N/A
Reserve a room from a block	N/A
Test coverage	N/A
Fundamentals
Names variables, classes and modules appropriately	yes
Understanding of variable scope - local vs instance	yes
Can create complex logical structures utilizing variables	yes
Appropriately uses methods to break down tasks into smaller simpler tasks	yes - you've done a particularly good job of this
Understands the differences between class and instance methods	yes
Appropriately uses iterators and Enumerable methods	yes
Appropriately writes and utilizes classes	yes
Appropriately utilizes modules as a namespace	yes
Wrap Up
There is a refactors.txt file	no
The file provides a roadmap to future changes
Additional Feedback	Great job overall! This code is well-designed, well-written and well-tested. I've left a few inline comments below, but in general I like what I see. Keep up the hard work!

[droberts-sea]

When we said "access the list of all of the rooms in the hotel", we meant being able to call a method and get back an array of whatever your program uses to represent rooms. The attr_accessor :rooms above accomplishes this, and this method is not needed.

[droberts-sea]

Good use of the select enumerable to keep this code clean.

[droberts-sea]

until is used to make a loop, but the body of this loop only runs once. You might want unless here instead.

[droberts-sea]

I love the problem solving approach here - you've done a good job of taking a big difficult problem (figure out which rooms are free) and turning it into two smaller problems (figure out which rooms are occupied, then take the inverse of that list).

[droberts-sea]

I like the decision to make this a method rather than storing the cost as an instance variable. That way if the number of nights or the cost per night were to change (say in a future version of the program), the total cost will automatically be correct.

[droberts-sea]

It might be wise to break each of these out as a separate test. That way if one fails, you know exactly what went wrong and have a nice human-readable name for it.