我刚刚发现自己创建了一个名为“InstructionBuilderFactoryMapFactory”的类。这是一个类的 4 个“模式后缀”。它立刻让我想起了这一点：
http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern
这是设计的味道吗？我应该对这个数字施加限制吗？
我知道一些程序员对其他事情有类似的规则（例如，在 C 中不超过 N 级指针间接。）
所有的课程对我来说都是必要的。我有一个从字符串到工厂的（固定）映射——我一直在做的事情。该列表越来越长，我想将其移出使用构建器的类的构造函数（由从地图获得的工厂创建......）并且像往常一样，我避免使用单例。
一个好的提示是：您的类公共 API（包括它的名称）应该揭示意图，而不是实现。我（作为客户）不在乎您是实现了构建器模式还是工厂模式。
不仅类名看起来很糟糕，而且它也没有说明它的作用。它的名字是基于它的实现和内部结构。
我很少在类中使用模式名称，除了（有时）工厂。
编辑：
在 Coding Horror 上找到一篇关于命名的有趣文章，请查看！
我将其视为一种设计气味——它会让我思考是否所有这些抽象级别都足够重要。
我不明白你为什么要命名一个类'InstructionBuilderFactoryMapFactory'？是否还有其他类型的工厂——不会创建 InstructionBuilderFactoryMap 的工厂？或者是否需要映射任何其他类型的 InstructionBuildersFactories？
当你开始创建这样的类时，这些是你应该考虑的问题。可以将所有这些不同的工厂工厂聚合成一个，然后提供不同的方法来创建工厂。也可以将这些 factory-factory 放在不同的包中，并给它们一个更简洁的名称。想一想这样做的替代方法。
类名中的许多模式绝对是一种气味，但气味并不是一个明确的指标。这是一个“停下来重新思考设计”的信号。很多时候，当您坐下来思考更清晰的解决方案时，就会变得显而易见。有时由于手头的限制（技术/时间/人力/等）意味着现在应该忽略气味。
至于具体的例子，如果没有更多的上下文，我认为花生画廊的建议不是一个好主意。
我一直在想同样的事情。就我而言，工厂的丰富是由“为可测试性而构建”引起的。例如，我有一个这样的构造函数：
ParserBuilderFactoryImpl(ParserFactory psF) {
...
}
这里我有一个解析器——我需要的终极类。解析器是通过调用构建器上的方法来构建的。构建器（需要构建的每个解析器的新构建器）是从构建器工厂获得的。
现在，什么 h..l 是 ParserFactory？啊，我很高兴你问！为了测试解析器构建器的实现，我需要调用它的方法，然后查看创建了哪种解析器。在不破坏构建器正在创建的特定解析器类的封装的情况下执行此操作的唯一方法是在创建解析器之前放置一个拦截点，以查看其构造函数中的内容。因此 ParserFactory。这只是我在单元测试中观察传递给解析器构造函数的一种方式。
我不太确定如何解决这个问题，但我有一种感觉，我们最好传递类而不是工厂，如果 Java 可以有适当的类方法而不是静态成员，它会做得更好。