お役ご免ってのは言い過ぎでしょう。後々機能追加が考えられる場合、
その機能追加に耐える様Interfaceを定義するコトなんて、（自分は）ザラにありますよ。
たとえば、画像ファイルに対して順次いろんな処理をするようなソフトを作ったとき、
最初はjpgとbmpしか対応しないでおいて、いずれpngとかtiffもやりたいなあ、と思った場合、

interface ImageProcessor { ... }
class JpegImageProcessor { ... }
class BmpImageProcessor { ... }

なんて。
処理自体が短ければ>>18の言うとおり、ラムダ式で十分なんだけど、
色んな段階を踏む処理の場合、処理自体をクラス化しちゃう方が後々追加し易い。

>2つの似たようなクラスを両方保持して〜一つの具体クラスをただ書き換えるほうがずっといい

っていうような懸念がある場合は、interfaceじゃなくて抽象クラスでやればいいし。
共通部分は抽象クラスで処理して、後々追加したい機能毎に変わりうる部分は具象クラスに任せて抽象メソッドを定義だけしておく、とか。