设计Java程序的分歧

Question

我们正在设计一个系统，该系统将具有多个“处理器”，这些“处理器”在网络中相互通信以完成某项任务。

实际上，这应该成为一个将由公司的几个团队使用的库。

我们正在使用Avro来定义处理器将接受的输入和输出类型。到现在为止还挺好。但是现在，我的一些同事正在游说通过默默地执行一些转换来为简单类型提供“更大的灵活性”，例如int - ＆gt; long（fine）或String - ＆gt; int（不!!!）。我们的想法是Avro架构定义了处理器的工作原理，但在一些简单的情况下，我们应该让一个处理器输出一个int作为一个String与一个需要一个int的处理器...

我们正在就此进行辩论，我反对以下论点：

1. 我们应该有更多类型的安全性，现在便利可能是以后的错误来源;
2. 使用该机制，API将变得“模糊”，并且不能总是清楚您可以/不能发送给处理器的类型
3. 如果第一个版本没有这个机制并且需要严格的类型定义，我们可以放松一下，如果它真的是一个好主意，可以在以后开始做一些“转换”。但不知何故，这些论点似乎并没有成功。

“转换”机制的优点和缺点是什么？

Answer 1

我不认为这场辩论可以在技术优势上赢得或失败。在这个阶段，它涉及太多的主观问题。 （例如，需要灵活性的想法是主观的，因为类型转换相关的API不匹配将是一个问题。）

我处理争议的方式是指出价值转换框架将涉及复杂的（昂贵的，耗时的，潜在的风险，长期难以维护）扩展到正常的Avro做事方式。建议您不要使用此前端加载项目。相反，在您实施足够的实际功能以确定是否真的需要复杂性之前，请将其关闭。

Answer 2

我认为Java API的用户会期望Java行为。

Answer 3

我认为Robustness Principle可以帮到你：

  

在你所做的事情上保守一点，在你接受别人的事上保持自由（通常被改写为“在你所发送的内容中保守一点，在你所接受的内容中保持自由”）。

那就是说，我不主张编写你不需要的代码。为什么不按照你提议的方式去做，如果系统需要你的对手提出的额外能力，请按照你的建议稍后添加它？如果他们无法理解这一点，我真的会质疑他们是否正在倾听你的意见，也许会想出一种方法来改写你的观点。

Answer 4

如果处理器api针对它们需要/提供的类型进行了强类型处理，那么在编译时会免费进行大量错误检查。这是非常宝贵的。如果人们坚持支持转换，我可以想到一些（相当简单的实施）想法，这些想法不会失去这些好处：

1. 在构建处理器网络时，调用者必须明确提供＆＃34; glue＆＃34;处理器进行适当的转换。例如，如果Processor<I,O>表示输入类型为I且输出类型为O的处理器，则调用者将提供处理器以将字符串转换为整数。

2. 该框架可能包含一个＆＃34;类型的转换器注册表＆＃34; （类似Map<Pair<Class<I>,Class<O>>,Transformer<I,O>>），包含一系列标准转化，并允许用户添加新转化。构建处理器网络的开发人员可以选择使用严格的类型（上面的＃1），或让框架从注册表中自动选择类型转换处理器。