太多“图案后缀” - 设计气味？

我刚刚发现自己正在创建一个名为“InstructionBuilderFactoryMapFactory”的类。这是一个课程的4个“模式后缀”。这立刻让我想起了这一点：太多“图案后缀” - 设计气味？

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

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

我知道一些程序员有其他的事情类似的规则（例如不低于C.间接指针的N级以上）

所有类似乎有必要给我。我有一个从字符串到工厂的（固定）映射 - 我一直都在做。这个列表变长了，我想把它移出使用构建器的类的构造函数（这是由从地图获得的工厂创建的......）和往常一样，我避免了Singletons。

来源

2008-09-26 finnw

看，这就是为什么我讨厌Java。您（很有可能）在C++中看不到具有该名称的类。 – davr 2008-09-26 00:18:37

你使用的是IOC容器吗？ – 2009-02-05 00:34:56

我把它看作是一种设计的气味 - 如果所有这些抽象层次都拉动了足够的重量，它会让我觉得它。

我看不出为什么要命名一个类'InstructionBuilderFactoryMapFactory'？是否还有其他类型的工厂 - 不会创建InstructionBuilderFactoryMap？还是还有其他类型的需要映射的InstructionBuilder工厂？

这些是您在开始创建这些类时应该考虑的问题。可以将所有不同的工厂工厂集合成一个工厂，然后提供单独的方法来创建工厂。也可以将这些工厂放在不同的包装中，并给它们一个更简洁的名称。想想替代方法。

来源

2008-09-26 00:42:58 jop

很多类名中的模式绝对是一种气味，但气味不是一个明确的指标。这是“停一会儿，重新考虑设计”的信号。很多时候，你坐下来认为一个更清晰的解决方案变得明显。有时由于手头的限制（技术/时间/人力/等等），意味着现在应该忽略气味。

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

来源

2008-09-26 00:21:30

一个好的提示是：你的类公共API（包括它的名字）应该揭示意图，而不是实现。我（作为客户）不关心你是否实现了构建器模式或工厂模式。

不仅类名看起来不好，它也没有说明它的作用。它的名字是基于其实施和内部结构。

我很少在一个类中使用模式名，除了（有时）工厂。

编辑：

发现一个有趣的article关于编码恐怖命名，请检查出来！

来源

2008-09-26 00:26:17

InstructionBuilderFactoryMapFactory的名称如下 - 创建InstructionBuilderFactoryMap。客户端有一个合适的名称（简称“Parser”），用于它*做什么。为什么它*想要*一个IBFM没有透露，但它确实（在这种情况下是IBFMF）必须创建它。 – finnw 2008-09-26 00:31:11

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

ParserBuilderFactoryImpl(ParserFactory psF) { 
... 
}

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

现在，什么h..l是ParserFactory？啊，我很高兴你问了！为了测试解析器生成器实现，我需要调用它的方法，然后查看创建了哪种解析器。要做到这一点，只要不破坏构建器创建的特定解析器类的封装，就是在解析器创建之前放置一个拦截点，以查看构造器中的内容。因此ParserFactory。这只是我在单元测试中观察传递给解析器构造函数的一种方式。

我不太清楚如何解决这个问题，但我有一种感觉，我们应该更好地传递类而不是工厂，如果Java可以有适当的类方法而不是静态成员，那么Java会更好。

来源

2011-12-21 16:01:25 Arkadiy

太多“图案后缀” - 设计气味？

回答

相关问题