ruby 0.3-pez_class_original_gist.rb

Posted 2021-05-16

# OBJECTIVE 3: CREATE PEZ CLASS
# See objectives #1, #2, and #6 after #3
class PezDispenser
  @@available_flavors = %w(cherry chocolate cola grape lemon orange peppermint raspberry strawberry raspberry-lemon strawberry-vanilla)
  # Class variable describes current market available pez flavors (wikipedia; exclues sugarfree & sour)
  def initialize(flavors)
    unless flavors == flavors.select { |flavor| valid_flavor?(flavor) }
      raise ArgumentError.new('Contains invalid flavors') # raises if input includes invalid flavor
    end

    if flavors.length < 12 # pez dispensers hold 12 pez
      flavors.push(flavors.sample(12-flavors.length)).flatten!(1) #fills with random flavors from pool
    elsif flavors.length > 12
      flavors.replace(flavors.sample(12)) #randomly sample 12 if too large flavor pool on input
    end

    @flavors = flavors # Instantiates 12-item stack of pez from flavor pool (user story A)
  end

  def pez_count
    @flavors.length # Returns number of pez left (user story B)
  end

  def see_all_pez  # I thought it satisfied user story D better to display the pez in a list in the order they are coming up 
    puts @flavors.reverse
  end                               

  def add_pez(pez)
    until valid_flavor?(pez) do # Forces validation of input flavor
      print "Sorry. '#{pez}' is not a pez flavor. Try again. \nAdd pez type >> "
      pez = gets.chomp
    end                                                                     # If space, adds pez to top
    space? ? @flavors << pez : (puts 'All full! Eat some pez to add more.') # else, message
  end                                                                       # (user story D)

  def get_pez
    pez_count == 0 ? (puts 'All out! Sad trombone.') : @flavors.pop # Removes top-most pez
  end                                                               # (user story C)

  def space?
    true unless pez_count > 11 # Tests if space is available in pez dispenser
  end

  def valid_flavor?(pez)
    true unless !@@available_flavors.include?(pez) # Tests if an item is a valid pez flavor
  end
end

# OBJECTIVE 1: REVIEW & LIST COMPONENTS OF USER STORIES
#
#   User stories convey the WHO, WHAT, & WHY of a project requirement & ACCEPTANCE TESTING
#   procedures via the following components:
#
#   1) [3x5 index] CARD
#      These cards contains the following brief, informative and actionable statement
#      from a user in the format: “As a…I want to…so that…"
#   2) CONVERSATIONS
#      These are discussions between the developer and the user/product owner/stakeholder
#      where the user story may elaborate on difficult to interpret requirements and
#      provide background knowledge to assist implementation. These conversation also serve
#      as a place to update requirements if they have changed since written.
#   3) [acceptance] CRITERIA
#      Acceptance criteria should defined before development begins to determine when
#      each user story is finished, working and meets the users requirements.


# OBJECTIVE 2. UNDERSTAND THE TRANSLATION TO DRIVER CODE
#   A. I’d like to be able to “create” a new pez dispenser with a group of flavors that represent
#        pez so it’s easy to start with a full pez dispenser.
#   B. As a pez user, I’d like to be able to easily count the number of pez remaining in a dispenser
#        so I can know how many are left.
#   C. I’d like to be able to take a pez from the dispenser so I can eat it.
#   D. I’d like to be able to add a pez to the dispenser so I can save a flavor for later.
#   E. I’d like to be able to see all the flavors inside the dispenser so I know the order of
#        the flavors coming up
#
#   There are 5 methods represented by the test code: #initialize (implicit via constructor)
#                                                     #pez_count
#                                                     #see_all_pez
#                                                     #add_pez
#                                                     #get_pez

flavors = %w(cherry chocolate cola grape lemon orange peppermint raspberry strawberry).shuffle
super_mario = PezDispenser.new(flavors) #=> This and the previous line target user story A

puts "A new pez dispenser has been created. You have #{super_mario.pez_count} pez!"
puts 'Here\'s a look inside the dispenser:'
puts super_mario.see_all_pez #=> Targets user story E

puts 'Adding a purple pez.'
super_mario.add_pez('purple') #=> Targets user story D

puts "Now you have #{super_mario.pez_count} pez!" #=> Targets user story B
puts 'Oh, you want one do you?' #=> Snarky? Maybe...
puts "The pez flavor you got is: #{super_mario.get_pez}" #=> ...Targets user story C
puts "Now you have #{super_mario.pez_count} pez!"

# OBJECTIVE 6. REFLECT & REVIEW
#  I decided to add two helper methods in addition to the 5 represented in the driver code in order to
#  improve clarity of my code and keep things DRY. I'm unsure if it helped or not...I also wanted to 
#  avoid raising an error for an invalid flavor when adding a pez, so I tried out a input validation 
#  loop prompting satisfied only when a valid flavor is entered. I thought this was a good challenge for 
#  beginning to understand how software development integrates with the (Agile) project lifecycle.
#  I found myself wanting more information on some of the user requests to understand if my approach 
#  would meet said requirement--would benefit from conversation component...