Return to Answer

here is my attempt. I've written it in Ruby. Positives: things are broken down, a method is hardly more than a 10 lines. This makes it eas(ier) to read and later change if you need to. You don't want to plan too far for unexpected things in the future, but just have somewhat of an idea what the boss might turn around and say. So long as the code does it's job and is easy to read, then you're halfway there.

Things become tricky when you need to add functionality. That's why the exercise of adding other operations to your code: addition, or adding multiple numbers, becomes interesting. You are forced to refactor your code to those considerations.

The key thing to take out of this:

the key thing to take out of it is that there are many methods working together, rather than everything put in one method. it's broken down in many parts and simplified. if you compare your code above with the code below, the code below breaks it down into many many problems and methods. try to do the same. perhaps i would recommend you rewriting your code again to consider this particular principle. then use object oriented concepts to rewrite the code again.

Breakdown:

• created a question class
• i've created a quiz class which holds all the questions in an array.
• my question class is doing more than one thing: it is bloated and has more than one responsibility. is this acceptable? In this case, it will do.
• very tightly coupled. this is procedural programming more so than object orientated. i'll have this as a kata and redo this problem with a more OOP approach.

Code is on git hub so you can read/edit download it:

https://github.com/BKSpurgeon/maths_quiz/blob/master/quiz.rb

here is my attempt. I've written it in Ruby. Positives: things are broken down, a method is hardly more than a 10 lines. This makes it eas(ier) to read and later change if you need to. You don't want to plan too far for unexpected things in the future, but just have somewhat of an idea what the boss might turn around and say. So long as the code does it's job and is easy to read, then you're halfway there.

Things become tricky when you need to add functionality. That's why the exercise of adding other operations to your code: addition, or adding multiple numbers, becomes interesting. You are forced to refactor your code to those considerations.

The key thing to take out of this:

the key thing to take out of it is that there are many methods working together, rather than everything put in one method. it's broken down in many parts and simplified. if you compare your code above with the code below, the code below breaks it down into many many problems and methods. try to do the same. perhaps i would recommend you rewriting your code again to consider this particular principle. then use object oriented concepts to rewrite the code again.

Breakdown:

• created a question class
• i've created a quiz class which holds all the questions in an array.
• my question class is doing more than one thing: it is bloated and has more than one responsibility. is this acceptable? In this case, it will do.
• very tightly coupled. this is procedural programming more so than object orientated. i'll have this as a kata and redo this problem with a more OOP approach.

Code is on git hub so you can read/edit download it:

https://github.com/BKSpurgeon/maths_quiz/blob/master/quiz.rb

• created a question class
• i've created a quiz class which holds all the questions in an array.
• my question class is doing more than one thing: it is bloated and has more than one responsibility. is this acceptable? In this case, it will do.

the quiz class:

class Quiz 
attr_accessor :questions, :mark_tally
def initialize()
 @questions = []
 @mark_tally = 0
end
def create_quiz 
 1.upto(5) do |i|
 create_question 
 end
end
def create_question
 @questions << Question.new(rand(1..12),rand(1..12))
end
def administer_quiz
 @questions.each do |question|
 administer_question(question) 
 end
end
def administer_question(question)
 question.ask
 question.obtain_answer
 question.is_correct?
 question.print_correct
end
def obtain_final_marks
 @questions.each do |question|
 add_question_to_mark_tally(question)
 end
end
def print_final_marks
 puts "You got #{@mark_tally} correct."
end
def add_question_to_mark_tally(question)
 if question.is_correct?
 @mark_tally += 1
 end
end
end

the question class:

class Question 
 attr_accessor :number1, :number2, :correct_answer, :user_answer, :correct
 
def initialize(number1, number2)
 @number1 = number1;
 @number2 = number2;
 calculated_answer
end
def ask()
 puts "What is #{number1} * #{number2}?\n"
end
def calculated_answer
 @correct_answer = @number1 * @number2
end
def print_correct
 if @correct
 puts "Correct!"
 else
 puts "Incorrect!"
 end
end
def is_correct? 
 if correct_answer == user_answer
 @correct = true
 else
 @correct = false
 end
end
def obtain_answer
 begin
 print( "Enter answer:" )
 @user_answer = gets().chomp().to_i 
 rescue => e # - this catches StandardError and is usually enough
 @user_answer = 0
 puts( "Error: #{e}\nPlease try again." ) # <-- changed here
 retry # retry on exception
 else 
 return @user_answer
 end
end
end

And this actually runs the code:

test_quiz = Quiz.new
test_quiz.create_quiz
test_quiz.administer_quiz
test_quiz.obtain_final_marks
test_quiz.print_final_marks

• created a question class
• i've created a quiz class which holds all the questions in an array.
• my question class is doing more than one thing: it is bloated and has more than one responsibility. is this acceptable? In this case, it will do.
• very tightly coupled. this is procedural programming more so than object orientated. i'll have this as a kata and redo this problem with a more OOP approach.

Code is on git hub so you can read/edit download it:

https://github.com/BKSpurgeon/maths_quiz/blob/master/quiz.rb

the below is not the best abstraction; I hope you can make sense of it; stack overflow just kills the formatting. but the key thing to take out of it is that there are many methods working together, rather than everything put in one method. it's broken down in many parts and simplified.

the key thing to take out of it is that there are many methods working together, rather than everything put in one method. it's broken down in many parts and simplified. if you compare your code above with the code below, the code below breaks it down into many many problems and methods. try to do the same. perhaps i would recommend you rewriting your code again to consider this particular principle. then use object oriented concepts to rewrite the code again.