太多＆＃8220;模式后缀＆＃8221; - 设计气味？

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 Horror的命名，请查看！

Answer 3

班级名称中的许多模式绝对是一种气味，但气味并不是一个明确的指标。这是一个“停一分钟并重新考虑设计”的信号。很多时候，当你坐下来思考更明确的解决方案时。有时由于手头的限制（技术/时间/人力等）意味着现在应该忽略气味。

至于具体的例子，我不认为没有更多背景的花生画廊的建议是个好主意。

Answer 4

我一直在想同样的事情。就我而言，工厂的丰富程度是由“可测试性的构建”引起的。例如，我有一个像这样的构造函数：

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

这里我有一个解析器 - 我需要的终极类。 解析器是通过调用构建器上的方法构建的。 构建器（需要构建每个解析器的新构建器）从构建器工厂获得。

现在，h..l是什么是ParserFactory？啊，我很高兴你问！为了测试解析器构建器实现，我需要调用它的方法然后看看创建了什么类型的解析器。执行此操作的唯一方法是打破构建器正在创建的特定解析器类的封装，即在创建解析器之前放置一个拦截点，以查看其构造函数中的内容。因此ParserFactory。这只是我在单元测试中观察传递给解析器构造函数的方法。

我不太确定如何解决这个问题，但我觉得我们最好不要在类而不是工厂周围传播，如果Java可以有适当的类方法而不是静态成员，那么Java会做得更好。 / p>