4 ms·
One of the good things about this is it's easy to change the definition of "multiple_of_3" to reflect changing requirements. For example, suppose we wanted Fizz
by brabbins 14y ago
One of the good things about this is it's easy to change the definition of "multiple_of_3" to reflect changing requirements. For example, suppose we wanted Fizz to be printed with multiples of 7 instead. Easy! Just change:
def multiple_of_3(number):
number % 3 == 0
end
to
def multiple_of_3(number):
number % 7 == 0
end
Now perhaps he sees the advantage: no refactoring necessary.
(* I feel I should say that I am being sarcastic. Anyone who thinks it's ok to have a function called "multiple_of_3" that checks if it is a multiple of 7 should probably be fired immediately.)
- ashray 14y agoYes, I see your point. But in this case if I wanted to change it to do it on 7, I'd have to make a change in 3 places. 1. The function definition (def multiple_of_3) 2. The function contents (number % 3 == 0) 3. The function call(s). If I didn't try to use functions on this, I'd just have to change a single line (or two at the most) in my program and get on with it. Your use case is exactly what I meant when I said that breaking such a simple problem into functions actually introduces complexity.
- zacharydanger 14y agoYeah. Those functions should've been defined as def fizz?(i) i % 3 == 0 end def buzz?(i) i % 5 == 0 end So that he'd just need to change them once.