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

Lots of patterns in a class name is most definitely a smell, but a smell isn't a definite indicator. It's a signal to "stop for a minute and rethink the design". A lot of times when you sit back and think a clearer solution becomes apparent. Sometimes due to the constraints at hand (technical/time/man power/etc) means that the smell should be ignored for now.

As for the specific example, I don't think suggestions from the peanut gallery are a good idea without more context.

Answer 2

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!

Answer 3

I see it as a design smell - it will make me think if all those levels of abstraction are pulling enough weight.

I can't see why you wanted to name a class 'InstructionBuilderFactoryMapFactory'? Are there other kinds of factories - something that doesn't create an InstructionBuilderFactoryMap? Or are there any other kinds of InstructionBuildersFactories that it needs to be mapped?

These are the questions that you should be thinking about when you start creating classes like these. It is possible to just aggregate all those different factory factories to just a single one and then provide separate methods for creating factories. It is also possible to just put those factory-factory in a different package and give them a more succinct name. Think of alternative ways of doing this.