You are quite right. My code showed what I intended, but I garbled the
explanation. Single method with switches should be private for
implementation, and I tend to use that to make the code DRYer. Multiple
methods for the exposed interface.
Normally I'd start with multiple (separate) methods and create the
private function when there was an obvious need to refactor and
opportunity to make the code DRYer.
This topic really bothers me. ;-) The tendency to see more Ruby
(mostly Rails) code use option hashes all over the place is sloppy
(IMO). The interface is less clear. Behaviour breaks or changes
unexpectedly. It's just bad practice.
Branching isn't DRY. So maybe there's a responsibility they all share
that could be extracted. In this case maybe that's generating X
characters of padding. That could be extracted. But making a "meta-
method" is not in itself DRY. In fact, the goal of DRYness seems to
lately be trumping longer standing lessons of loose coupling, cohesive
code, composition over inheritance, seperation of concerns, etc. All
of these should be much higher priority than DRYness. In fact, to go
to an extreme, you'll end up with much nicer code if you completely
abandon attempts at DRYness outside of your business layer and instead
focus on composition, cohesion and SoC.
Just one ranter's opinion. ;-)
DRY is the new new, and like every other that came before it, the most
recent probably being Design Patterns, it's being over-used and abused
to the detriment of code quality.