Today we tackled a number of problems with a common strategy: recursion. This also could have been called ‘return value day’ because it continually drove in the importance in OOD of considering return value to the exclusion of all else.
What does this mean in effect, and how does it relate to recursion? Well, recursive problems are notoriously difficult for a number of reasons. As hackers, we are accommodated to visualizing a stack trace when composing and debugging our procedures. Not too difficult when you’re iterating over an array, or even recursively deriving a Fibonacci sequence. When trees come into the picture, it becomes a lot more difficult to visualize the big picture.
Consideration of the return value helps in two regards. It allows us to being composing our methods by considering base cases - where our recursive algorithms terminate, and from which our recursive trees are derived. And it defangs the unintuitive tendency of recursion: yes, in the big scheme of things, you’re calling a method that calls itself that calls itself that… but right here, right now, you’re getting a return value from a method. And since we are such good coders, the method is probably named something obvious and direct - like ‘make change’ or ‘fibonacci numbers’ - right?