About
A CLI app, which takes in a list of integers and prints out the next big palindrome for each of them
Usage
- An sbt project.
sbt test
runs the testssbt run
with correct arguements, runs the program
Design Notes
It is unnecessary to parameterize our app with the number of test cases
We can just pass in an array of inputs and the app prints out the corresponding next palindromes to the console.
Why Stream based solution?
Streams were used to answer the question, ‘What do we do if the input contains a palindrome itself?’
Going strictly by the brief, we are then required to output the next big palindrome. So if this edge case isn’t handled, the program would work well on non palindrome inputs, but with palindromes, it might just print them as is.
So if we plan to terminate our computation of searching for the next palindrome purely on the basis of whether the current number being tested is a palindrome or not, the program won’t handle initial inputs which are also palindromes.
The design of the CLI
CLI.scala houses the interface to our application’s core logic. CLI in this case is just a procedure, which calls core methods on our input array to finally transform it into a string, which is then just printed to the console. It happens as per the following plan.
args
is the input array- drop
args
’ head, we don’t need it - map a
_.toInt
to parse the String to Int - map
validate
to transform the array of ints to an array of optional ints - map those optional ints with
nextPal
to get the next palindrome - map those optional next palindromes, each with
getOrElse(-1)
to unwrapSome
- wherever the input is invalid, we get an error code
-1
- now we just make string out of this array and print to console
The separation of backend logic, into individual methods, improves testability, as each individual component can be tested independently.