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

my solution to the exercise #23

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions Queue.rb
Original file line number Diff line number Diff line change
@@ -1,13 +1,22 @@
#FIFO
class Queue
def initialize
@store = []
end

def dequeue
@store.pop
end

def enqueue(element)
@store.unshift element
end

def size
@store.length
end

def empty?
size == 0
end
end
8 changes: 8 additions & 0 deletions Stack.rb
Original file line number Diff line number Diff line change
@@ -1,14 +1,22 @@
#LIFO
class Stack
def initialize
@store = Array.new
end

def pop
@store.shift
end

def push(element)
@store << element
end

def size
@store.length
end

def empty?
size == 0
end
end
43 changes: 43 additions & 0 deletions job-simulation.rb
Original file line number Diff line number Diff line change
@@ -1,4 +1,47 @@
require './Stack.rb'
require './Queue.rb'

class Company
MAX_EMPLOYEES = 6

attr_reader :waiting, :working

def initialize
@waiting = Queue.new
10.times { |i| wait! i+1 }

@working = Stack.new

end_of_the_month
end

def end_of_the_month
fire!
hire!
end

private

def hire!
until working.size >= MAX_EMPLOYEES
new_hire = waiting.dequeue
working.push new_hire
end
end

Choose a reason for hiding this comment

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

Any reason we should temporarily store new_hire? Could we do this working.push(waiting.dequeue) instead?

Copy link
Author

Choose a reason for hiding this comment

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

We could; it's a personal preference. I call it out (by allocating a local variable) because .dequeue mutates waiting.


def fire!
return if working.empty?

Choose a reason for hiding this comment

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

This is a great check, but what if it happens a few iterations into the following loop? We aren't checking for it there -- should we?

Copy link
Author

Choose a reason for hiding this comment

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

I'd have to write a test to know for sure. :) But I don't think so, given the limited interface of the class. Only the end_of_the_month method is public, though, so unless folks reach into the private methods (and I'm sure that would never happen), working will always have 10 elements when fire! is invoked, except the very first time it's called during object initialization. I could likely refactor the guard out if I called hire! directly during initialize instead of end_of_the_month, but I'd want tests in place before doing so.

number_to_fire.times do
fired_person = working.pop
wait! fired_person

Choose a reason for hiding this comment

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

Same question here questioning the necessity of fired_person. Maybe we could say wait! working.pop, unless for some reason we don't want to do that? Maybe if working.pop returns nil somehow?

end
end

def wait!(person)
waiting.enqueue person
end

def number_to_fire
rand(6) + 1
end
end