It's good coding practice to restrict mutability. As the instance variables are never changed we can make them immutable. Even better: Thus the whole class Dinglemouse becomes immutable - an instance of Dinglemouse can never be changed after initialization. As for the parameters it might not be mandatory to declare them final, but I made it a habit to declare all variables final by default, unless for the rare occasion where I really need a mutable variable. Also it is best avoided to change the value of parameters, so declaring them final makes this more explicit.

I think that the description can be misleading insofar as it doesn't explicitly mention what should happen to non-alphabetic characters. Should they degrade at all? If you think of a real-life photocopier, you might assume, that even numbers and special characters can decay over time. This led me to wrongly allowing the whitespace character as a legal successor in the copy to just any original character.

So although the description and the test cases implicitly define the expected behavior, a more explicit hint would be very helpful. I suggest an extra bullet point under "Notes" stating that other characters do not degrade, as @docgunthrop already proposed.

I'd like to join in on the praise. A really nice series of katas. Thank you.

The test cases are missing the required imports for java.util.Arrays as well as for org.junit.Assert and org.junit.Test. I think it should really not be put on the shoulders of the solver of this kata to fix the imports to be able run the local test cases at all.

Chapeau!

I just thought that this is what was really missing here: Some more test cases, to make sure that it really works as expected.

Interestingly enough, the tests for the edge cases reveal how the current solution differs from the original implementation, which is the way how negative as well as very large input resulting in overflow is handled. While the current implementation throws a NumberFormatException in those cases, the original version of the algorithm would not throw at all and instead produce the following results:

I strongly agree. Also with the return type being int I missed a clear expectation of how overflow should be handled. The expectation is only defined implicitly by the (failing) tests, which is not the nicest way to define how to handle these cases.

One alternative to the magic-number-conversion would be to use Character.digit(). And some more nitpicking: The import for IntStream is not necessary.

Other than that I agree that this is the best solution I've seen here (after my own of course ;) ).

I like it.

No null-check for the varargs? Tisk tisk...

Very clever idea. But ... what if the sum of on and wait is twice cap or bigger?

For example let's say cap = 10, on = 20, wait = 30, then the result would be (20 + 30) % 10 = 50 % 10 = 0.

• Constants should really be declared as constants, i.e. static final.
• No need to ever import anything from java.lang (unless you want to do a static import).

ArithmeticException is a subclass of RuntimeException. RuntimeException and Error are called unchecked in Java terminology, because they do not need to be declared in a throws clause of a method. That's because they are meant to represent programming problems, that client code cannot expect to recover from (see the documentation and this short article for the details).

So my question is: Why should one declare such an exception? You wouldn't generally declare NullPointerExceptions, would you? I think it would be more appropriate, to document this kind of exception in a doc comment: /** @throws ArithmeticException if the result overflows a long */

Quite readable. You could get rid of the if-checks, which are redundantly testing for the initial for-condition.