About modelling behaviour. More parameters on function, or new function?

Question

First, let me set up some context.

I have a function that simulates a user typing a string, printing each character of the buffer at a fixed delay.

But now, I want another behaviour. There has to be a random delay if the user wants, so it will now print each character at a random delay between two numbers.

1. If you add this behaviour to a separate function, it would be almost the same, a copy-paste, except that for now, it takes a tuple (float, float) that specifies the upper bound and lower bound of the random number to be generated.
2. But if you had this functionality on the same function that takes a fixed delay, you would need to add extra parameters, such as random_delay to be true or false, and then another param to receive the tuple for the boundaries.
3. You can also make the delay parameter, to take a tuple or float, type check it, and take the path accordingly to the type. The function also has the new parameter random_delay that takes true or false. But this strategy and 2 leads to the question. Doesn't a new behaviour lead inherently to belong to a new function?

I am a student going through a more analytical approach building stuff and will be great to hear your opinion about it, even for such a simple problem. Would you use option 1, 2 or 3, or even take another approach? Thanks for your insight.

Answer 1

Write one function that has all of the functionality and options you need. Then write simpler overloads that call your first function with meaningful default argument values.

Foo Bar(Tuple<float, float> baz, bool qux); 
{ 
    // Implementation here 
}

Foo Bar(Tuple<float, float> baz)
{
    Bar(baz, false);
}

Foo Bar()
{
    Bar(new Tuple<float, float>(1.0, 2.0), false);
}

If your programming language of choice has "default arguments," this is made much easier, as you would then only need a single function to do it all.

Answer 2

If your requirements are really just as simple as this, then Robert Harvey's answer is adequate.

However, if requirements continue to develop, you will reach a point at which adding more parameters to a function makes it hard to maintain.

If I were faced with your situation and had to come up with a solution with future expansion in mind, I would consider creating an interface to represent a class that supplies the delay between characters appearing. I could then create two concrete implementations - one that always returns a constant value, and one that returns a random number (and the lower and upper bounds for this range would be the constructor parameters for this new class).

The code for writing to the display would then be written against this interface, with the appropriate implementation being created at the appropriate time beforehand.