太多的“模式后缀”-设计的味道？

Question

我刚刚创建了一个名为"InstructionBuilderFactoryMapFactory“的类。在一个类上有4个“模式后缀”。它立刻让我想起了这一点：

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

这是设计的味道吗？我应该对这个数字施加限制吗？

我知道有些程序员对其他事情也有类似的规则(例如，C中不超过N级的指针间接寻址)。

对我来说，所有的课程都是必要的。我有一个从字符串到工厂的(固定的)映射--这是我一直在做的事情。这个列表越来越长，我想把它移出使用构建器的类的构造器中(这些构建器是由从映射中获得的工厂创建的……)和往常一样，我也在避免单身者。

Answer 1

我把它看作是一种设计的味道--它会让我思考那些抽象的层次是否足够重要。

我不明白为什么要将一个类命名为“InstructionBuilderFactoryMapFactory”？有没有其他类型的工厂--不能创建InstructionBuilderFactoryMap的工厂？或者，是否有任何其他类型的InstructionBuildersFactories需要映射？

当您开始创建这样的类时，您应该考虑这些问题。可以将所有这些不同的工厂聚合成一个单独的工厂，然后提供单独的方法来创建工厂。也可以将这些工厂-工厂放在一个不同的包中，并给它们一个更简洁的名称。想一想做这件事的其他方法。

Answer 2

一个很好的提示是:您的类公共API (包括它的名称)应该揭示意图，而不是实现。我(作为客户)并不关心您是实现了构建器模式还是工厂模式。

不仅类名看起来很糟糕，它也没有告诉我们它做了什么。它的名字是基于它的实现和内部结构。

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

编辑：

在Coding上找到了一个关于命名的有趣的article，请查看！

Answer 3

在类名中有很多模式肯定是一种气味，但气味并不是一个明确的指示器。这是一个信号，“停一分钟，重新考虑设计”。很多时候，当你坐下来思考一个更清晰的解决方案时，你会发现。有时由于手头的限制(技术/时间/人力/等等)意味着现在应该忽略气味。

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