对于不明确的API，是否存在不公开需求的命名反模式？

Question

在我正在评估的源代码(扎贾尔)中，有一些java代码可以这样使用：

JarJarTask fixture = new JarJarTask();
fixture.addConfiguredRule(new Rule());
fixture.execute();

它将引发一个异常，如：

java.lang.IllegalArgumentException:
The <rule> element requires both "pattern" and "result" attributes.

现在，在我看来，API显然不是最优的--如果规则元素需要这些属性，它应该在构造函数中请求它们(或者提供一个Builder或类似的需要它们的类)。但我无法找到编码约定或java编程建议来同意我的观点。

是否有一些具体的名称，我可以用来查找这个研究，编程文学，风格指南？我可以用哪些术语来讨论这个问题呢？

当然，这是用一些术语在某个地方讨论过的，但我似乎找不到任何东西。

我确实发现了关于构造器注入的讨论，如Kent在Smalltalk最佳实践模式和马丁·福勒中所提出的，根据这的说法，这使得它“立即明确了类在实例化时需要什么，而且如果不传递字段的对象，就不可能实例化类”。因此，这是一个起点，至少可以找到一些讨论。

Answer 1

这里您要做的最好的事情就是说明API不是什么，或者它没有提供什么。构造函数与设置器注入是一个附带的过程，但原则是合理的:编写类，以便从构造函数参数中清楚地知道创建一个完整的函数对象所需的内容。

如果您遵循组织中的最佳实践，只需说明该类未能遵循在构造函数中描述其实例化要求的实践。

相关

按合同设计