0

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

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

我们使用 Avro 来定义处理器将接受的输入和输出类型。到目前为止，一切都很好。但是现在，我的一些同事正在游说通过静默执行一些转换来为简单类型提供“更大的灵活性”，例如 int -> long（精细）或 String -> int（否！！！）。这个想法是 Avro 模式定义了处理器的工作原理，但在一些简单的情况下，我们应该让一个将 int 作为字符串输出的处理器与需要一个 int 的处理器对话......

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

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

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

4

4 回答 4

2

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

我处理争议的方式是指出，价值转换框架将涉及对正常 Avro 做事方式的复杂（昂贵、耗时、潜在风险、难以长期维护）扩展。建议你不要用这个预先加载项目。而是推迟它，直到您实现了足够的实际功能来决定是否真的需要复杂性。

于 2012-09-20T00:46:43.007 回答
1

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

于 2012-09-20T00:32:00.087 回答
1

我认为稳健性原则可以帮助你：

在你所做的事情上保持保守，在你从他人那里接受的东西上保持自由（通常被改写为“在你发送的东西上保持保守，在你接受的东西上保持自由”）。

也就是说，我不提倡编写你不需要的代码。为什么不按照您提议的方式进行，如果系统需要您的对手提议的额外功能，请稍后按照您的建议添加？如果他们不能理解这一点，我真的会质疑他们是否在听你的话，也许会想办法重新表达你的论点。

于 2012-09-20T00:37:25.870 回答
1

如果处理器 api 关于它们需要/提供的类型是强类型的，那么您会在编译时免费获得大量错误检查。这是无价的。如果人们坚持支持转换，我可以想到一些（相当容易实现的）想法，它们不会失去这种好处：

  1. 在构建处理器网络时，调用者必须显式提供执行适当转换的“粘合”处理器。例如，如果Processor<I,O>代表一个具有输入类型I和输出类型的处理器O，那么调用者将提供一个处理器来从字符串转换为整数。

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

于 2012-09-20T00:59:11.097 回答