Too many pattern suffixes - smell design?

Question

I just created a class for myself called "InstructionBuilderFactoryMapFactory". These are 4-inch pattern suffixes in the same class. It immediately reminded me of this:

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

Is that a designer smell? Should I impose a limit on this number?

I know that some programmers have similar rules for other things (for example, no more than N levels of a pointer pointer in C.)

I need all the classes. I have a (fixed) map from rows to factories - I do something all the time. The list is longer, and I want to move it from the constructor of the class, which uses collectors (created by factories that are received on the map ...) and, as usual, I avoid singletones.

Answer 1

I see it as a designer smell - it will make me think that all these levels of abstraction pull enough.

I don’t understand why you wanted to name the class "InstructionBuilderFactoryMapFactory"? Are there other plants - something that does not create an InstructionBuilderFactoryMap? Or are there any other types of instructions that need to be displayed?

These are questions that you should think about when you start creating such classes. You can simply combine all of these different factories with just one, and then provide separate methods for creating factories. You can also just put these factory -factory in another package and give them a more concise name. Think of alternative ways to do this.

Answer 2

Good tip: An open class API (and its name) should disclose intent, not implementation. I (as a client) don't care if you implemented a builder pattern or a factory pattern.

Not only does the class name look bad, but it says nothing about what it does. This name is based on its implementation and internal structure.

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

Edit:

Found an interesting article on naming in Coding Horror, please check this out!

Answer 3

The many patterns in the class name are certainly a smell, but smell is not a definite indicator. This is the signal "stop for a minute and rethink the design." Many times, when you sit back and think that a clearer solution becomes obvious. Sometimes due to restrictions (technical / temporary / male power / etc.) It means that the smell should be ignored at the moment.

As for a specific example, I don’t think that offers from the peanut gallery are a good idea without additional context.

Answer 4

I was thinking the same thing. In my case, the abundance of factories is caused by the "assembly for verification." For example, I have a constructor like this:

ParserBuilderFactoryImpl(ParserFactory psF) { ... } 

Here I have a parser - the final class I need. The parser is built by calling methods in the builder. The creators (new to each parser to be built) are derived from the builder factory.

Now, what h..l is a ParserFactory? Ah, I'm glad you asked! To check the implementation of the parser builder, I need to call its method, and then see which parser creator is created. The only way to do this without breaking the encapsulation of a particular parser class that the builder creates is to set an intercept point immediately before creating the parser to see what is included in its constructor. Therefore, ParserFactory. This is just a way to observe in a unit test what is passed to the parser constructor.

I'm not quite sure how to solve this, but I have a feeling that it would be better for us to bypass classes rather than factories, and Java would be better if it could have the correct class methods, rather than static members.