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

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.

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

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 4

I've been thinking the same thing. In my case, the abundance of factories is caused by "build for testability". For example, I have a constructor like this:

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

Here I have a parser - the ultimate class that I need. The parser is built by calling methods on a builder. The builders (new one for each parser that needs to be built) are obtained from builder factory.

Now, what the h..l is ParserFactory? Ah, I am glad you asked! In order to test the parser builder implementation, I need to call its method and then see what sort of parser got created. The only way to do it w/o breaking the incapsulation of the particular parser class that the builder is creating is to put an interception point right before the parser is created, to see what goes into its constructor. Hence ParserFactory. It's just a way for me to observe in a unit test what gets passed to the constructor of a parser.

I am not quite sure how to solve this, but I have a feeling that we'd be better off passing around classes rather than factories, and Java would do better if it could have proper class methods rather than static members.