actionscript-3 - 协议(protocol)简单性与 "properness"

Question

我和我的一个 friend 还有另一个争论。

考虑需要设计一个简单的基于 JSON 的协议(protocol)，该协议(protocol)基本上用于在各方之间发送某种事件(消息)。

说，像

 { event_id: 1, chat_message: "Hello" }
 { event_id: 2, group_id: 3, presence: "online" }
 ...

我建议像上面一样保留这个协议(protocol)，而我的 friend 建议做类似的事情:

 { event_id: 1, details: { chat_message: "Hello" } }
 { event_id: 2, group_id: 3, details: {  presence: "online" } }
 ...

他的论点是，就像 TCP 和 HTTP 处于不同的“责任”层一样，该协议(protocol)应该使用“详细信息”子对象以保持数据分离。

他的另一个论点是处理匹配事件的处理程序不应该知道任何有关“路由”信息(例如 event_id)的信息。

我的论点是:

我们正在增加每条消息的长度(以及网络流量，这对于与大量消息交换的系统可能很重要)，以便对处理程序隐藏这些信息

处理程序确实需要知道“路由”信息，例如，才能正确回答它们:

this.replyTo(event['event_id'], reply); // or...
this.replyTo(event, reply); 

即使我们需要从处理程序中隐藏 event_id 和类似的东西，我们也可以在传递给处理程序之前将它们去掉，这样仍然可以节省流量

该协议(protocol)非常简单，不应该被其他任何人使用。

做什么 你 思考？

Answer 1

经过大项目的长期经验，我必须强烈反对gahooa的和 Charlie Martin的建议。敏捷方法和经典方法之间存在很大的张力。他们的建议看起来很敏捷，但我不能同意。如果你设计了一些东西，千万不要以你现在就知道是错误的方式来设计它。这不是敏捷，是愚蠢。我无法相信您认为您的需求在 future 不会改变，因此请保持敞开大门并将重构影响降至最低。在您当前的设计中，当事件由不同的子系统作为事件类型分派(dispatch)器 -> 路由到组 -> 最终事件处理程序/存储或其他方式处理时，请保持每个子系统中的更改对彼此的影响最小。对我来说最好的负担是像洋葱皮芽这样的设计协议(protocol)，不要将它设计到您当前要求之外的每个细微细节。它很敏捷。

你的论点:

广告 1. 这是过早的优化。如果您确实需要最小化流量，请改用二进制协议(protocol)；-) ti 的其他方式成本/ yield 是错误的。

广告 2. 它适用于内部程序检测，而不是协议(protocol)本身。这是错误的设计，尤其是在 Erlang 中。您的处理程序不应该直接返回到目的地，而是返回到保持套接字所有权和类似情况的某个路由器(通常返回到调度程序)。看起来又是过早的优化!

广告 3. 我更喜欢相反的方法。为子系统提供最小的数据集以最大程度地减少副作用，简化(单元)测试并避免诱惑使用第 2 点的方法。必要时延长。不要以相反的方式进行。

P.S.:为什么你不命名你的事件，而是使用 id？再次过早优化？

编辑:澄清了 ID，这些是事件编号，但不是事件类。应该有另一个类键。