Too many "pattern suffixes" - design smell?

Question

I just found myself creating a class called "InstructionBuilderFactoryMapFactory". That's 4 "pattern suffixes" on one class. It immediately reminded me of this:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

Is this a design smell? Should I impose a limit on this number?

I know some programmers have similar rules for other things (e.g. no more than N levels of pointer indirection in C.)

All the classes seem necessary to me. I have a (fixed) map from strings to factories - something I do all the time. The list is getting long and I want to move it out of the constructor of the class that uses the builders (that are created by the factories that are obtained from the map...) And as usual I'm avoiding Singletons.

Answer 1

A good tip is: Your class public API (and that includes it's name) should reveal intention, not implementation. I (as a client) don't care whether you implemented the builder pattern or the factory pattern.

Not only the class name looks bad, it also tells nothing about what it does. It's name is based on its implementation and internal structure.

I rarely use a pattern name in a class, with the exception of (sometimes) Factories.

Edit:

Found an interesting article about naming on Coding Horror, please check it out!