Under or over-engineering?

Whenever you see classes called controler, provider, decider, manager, presenter, etc. which reassembles to some managerial job, you know that it isn't truly object oriented. It is actually procedural way of thinking, just packed in classes.

I just saw a class called ColorDecider, which has one public method, two private ones and no state at all. The only job of this class is to decide which color should be chosen based on the state of some other object. It is actually a replacement for a switch or dictionary in that object. It does the same job, but it looks smarter. Not for me.

But it has an interface, because it is nice thing to have. There are no other classes which implement this interface, because there can be only one way of presenting data in the system in one time, and it is defined by requirements. This behavior will be changed only if requirements change one day. So, why it needs a whole class?