我刚刚发现自己创建了一个名为" InstructionBuilderFactoryMapFactory"的类。在一个类中有4个"模式后缀"。它立即使我想起了这一点：

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

这是设计气味吗？我应该限制这个数字吗？

我知道有些程序员在其他方面也有类似的规则(例如，C语言中的指针间接访问级别不超过N个)。

所有的课对我来说似乎都是必要的。我有一个(固定的)从字符串到工厂的映射(我一直都在做)。列表越来越长，我想将其移出使用构建器的类的构造函数(由从地图获得的工厂创建的构建器...)而且像往常一样，我避免使用Singletons。

解决方案

一个类名中的很多模式绝对是一种气味，但是气味不是一个确定的指标。这是"停下来一会儿，重新思考设计"的信号。很多时候，当我们坐下来思考更清晰的解决方案时，就会变得很明显。有时由于手头的限制(技术/时间/人力/等等)，该气味现在应该被忽略。

至于具体示例，我认为没有更多上下文，花生画廊的建议就不是一个好主意。

一个很好的技巧是：类公共API(包括其名称)应该显示意图，而不是实现。我(作为客户)不在乎我们是实施构建器模式还是工厂模式。

不仅类名看起来很糟，而且它的作用也一无所获。它的名称基于其实现和内部结构。

除(有时)工厂工厂外，我很少在类中使用模式名称。

编辑：

找到了一篇有趣的文章，关于在"编码恐怖"中进行命名，请查看！

我将其视为一种设计气味，这会让我思考所有这些抽象层次是否都在发挥足够的作用。

我看不到我们为什么要命名一个类" InstructionBuilderFactoryMapFactory"？是否还有其他类型的工厂无法创建InstructionBuilderFactoryMap？还是还有其他需要映射的InstructionBuildersFactories？

这些是我们开始创建此类课程时应考虑的问题。可以将所有这些不同的工厂工厂汇总为一个工厂，然后提供创建工厂的单独方法。也可以将这些工厂工厂包装在不同的包装中，并为它们起一个更简洁的名称。考虑其他替代方法。