协议简单性与“适当性”的关系
我和我的一个朋友还有一次争论。
考虑需要设计一个基于 JSON 的简单协议，该协议基本上用于在各方之间发送某种事件（消息）。
比如说，
{ event_id: 1, chat_message: "Hello" }
{ event_id: 2, group_id: 3, presence: "online" }
...
我建议像上面一样保留这个协议，而我的朋友建议这样做：
{ event_id: 1, details: { chat_message: "Hello" } }
{ event_id: 2, group_id: 3, details: { presence: "online" } }
...
他的论点是，就像 TCP 和 HTTP 处于不同的“责任”层一样，这个协议应该使用“细节” " 子对象以保持数据分离。
他的另一个论点是，处理匹配事件的处理程序不应该知道任何有关“路由”信息（例如 event_id）的信息。
我的论点是：
- 为了向处理程序隐藏此信息，我们增加了每条消息的长度（以及网络流量，这对于与大量消息交换的系统可能很重要）
处理程序确实需要知道例如，“路由”信息，以正确回答它们：
this.replyTo(event['event_id'],reply); // 或者... this.replyTo(事件, 回复);即使我们需要从处理程序中隐藏 event_id 和类似的内容，我们也可以将它们删除 该
协议是非常简单，不应该被其他人使用。
你觉得怎么样？
I have another argument with a friend of mine.
Consider having a need to design a simplistic JSON-based protocol, which is basically used to send sort of events (messages) between parties.
Say, something like
{ event_id: 1, chat_message: "Hello" }
{ event_id: 2, group_id: 3, presence: "online" }
...
I propose to keep this protocol just like above, while my friend proposes to do something like:
{ event_id: 1, details: { chat_message: "Hello" } }
{ event_id: 2, group_id: 3, details: { presence: "online" } }
...
His argument is that just like TCP and, say, HTTP are at different layers of "responsibility", this protocol should use "details" sub-object in order to keep data separated.
Another argument he has is that handlers that handle matched event, should not know anything about "routing" information (things like event_id).
My arguments are:
- We're increasing length of each message (and network traffic, this might be important for a system that exchanges with a lot of messages) for the sake of hiding this information from handlers
Handlers do actually need to know "routing" information, say, to answer them properly:
this.replyTo(event['event_id'], reply); // or... this.replyTo(event, reply);Even if we'll need to hide event_id and stuff like that from handlers, we can just strip them out before passing to handlers and thus still save on traffic
This protocol is quite simple and is not supposed to be used by anybody else.
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
经过在大型项目的长期经验之后，我必须强烈不同意 gahooa 和 < a href="https://stackoverflow.com/questions/568074/protocol-simplicity-versus-properness/568113#568113">查理·马丁的建议。 敏捷方法和经典方法之间存在很大的张力。 他们的建议看起来很敏捷，但我不能同意。 如果你设计某样东西，永远不要以你现在就知道是错误的方式设计它。 它不敏捷，它很愚蠢。 我不敢相信你认为你的需求将来不会改变，所以保持开放并将重构影响降到最低。 当在您当前的设计中，事件由不同的子系统作为事件类型调度程序处理时 -> 路由器到组 -> 最终事件处理程序/存储或其他任何内容，在每个子系统中保持更改，彼此影响最小。 对我来说最实惠的是像洋葱皮这样的设计协议，不要将其设计到超出您当前要求的每个微妙细节。 它很敏捷。
你的论点：
ad 1.这是不成熟的优化。 如果您确实需要最小化流量，请改用二进制协议；-) ti 的其他方式成本/收益是错误的。
ad 2.它是针对内部程序仪表的工作，而不是针对协议本身。 这是错误的设计，尤其是在 Erlang 中。 您的处理程序不应直接返回到目的地，而是返回到某个路由器（通常返回到调度程序），该路由器保留套接字所有权等。 看起来又是一次过早的优化！
ad 3.我更喜欢相反的方法。 向子系统提供最小的数据集，以最大限度地减少副作用、简化（单元）测试并避免诱惑使用第 2 点的方法。 必要时延长。 不要以相反的方式去做。
PS：为什么你不命名你的事件而是使用id？ 又是过早优化？
编辑： Id 已澄清，这些是事件编号，但不是事件类别。 应该还有另一个班级钥匙。
After long experience at big project I must strongly disagree with gahooa's and Charlie Martin's suggestions. There is big tension between agile and classical approach. Their suggestions can look like agile but I can't agree. If you design something, never design it in way that you know is wrong even just now. It's not agile, it's dumb. I can't believe you think that your requirements will not change in future so keep doors open and refactoring impact minimal. When in your current design event is handled by different subsystems as event type dispatcher -> router to group -> final event handler/storage or whatever, keep change in each subsystem with minimal impact to each other. Best afford for me is design protocol like onion peels bud don't design it to each subtle detail outside your current requirements. It's agile.
You arguments:
ad 1. It is premature optimization. If you really need minimize traffic, use binary protocol instead ;-) Other way cost/benefit of ti is wrong.
ad 2. It is work for internal program instrumentation, not for protocol itself. It is wrong design especially in Erlang. Your handler should not return directly to destination but to some router (typically back to dispatcher) which keeps socket ownership and similar. It looks like premature optimization again!
ad 3. I prefer opposite approach. Provide minimal dataset to subsystems to minimize side-effects, simplify (unit) testing and avoid seduction to use approach from 2. point. Extend if necessary. Don't do it in opposite way.
P.S.: Why you don't name your event but use ids? Premature optimization again?
Edit: Ids are clarified, those are event numbers but not event classes. There should be another class key.
喜欢简单性……
当您编写规范、分布式系统以及将在您无法控制的许多不同情况下使用的系统时，需要适当性。
务实，使用“语言的力量”并编写代码来处理每种情况通常会更好。 除非需要，否则不要抽象。
保持简单。 保持快点。 保持干净。
你不知道它可能需要演变成什么（功能或性能），并且你拥有的抽象越多，重构就越困难。
Favor simplicity...
Properness will be needed when you are writing a specification, a distributed system, and one that will be used in many different circumstances outside of your control.
Being Pragmatic, it is oftentimes better to use the "power of the language" and just write code to handle each case. Don't abstract unless you need to.
Keep it simple. Keep it quick. Keep it clean.
You do not know what it may need to evolve into (features or performance), and the more abstraction you have, the harder it will be to re-factor.
曾几何时，当 ARPAnet 还很新、IP 还只是一个想法的萌芽时，有人说“哦，天啊，一个 32 位 IP 地址就足够了——四十亿个地址？没有人会这么做”永远需要它，我们可以将它们分成不同的地址类型，有足够的空间。”
25 年后，我们几乎不知道这会成为一个问题。
甚至不要跟我谈论域名。
重点是：你需要考虑什么可以改变。 仅仅为了优雅将其放入名称空间的层次结构中是不必要且浪费的，并且当您的额外层不能提供任何更多信息内容时，那为什么还要麻烦呢。
另一方面，如果您这样做是为了使代码对问题的变化不那么敏感，或者使实现明显更容易或更少出错，那么它可能是值得的。
那么你的答案是：它只是更优雅，还是还有其他优点？
Once upon a time when the ARPAnet was still new and IP was still a germ of an idea, someone said "Oh, gee, a 32 bit IP address is plenty -- four billion addresses? No one will ever need that. Hell, we can split them up into different address types, there's plenty of room."
Little did we know, 25 years later, that it would be an issue.
And don't even talk to me about domain naming.
The point is this: you need to think about what can change. Making this into a hierarchy of name spaces just for elegance's sake is unnecessary and wasteful, and when your extra layer doesn't provide any more information content, then why bother.
On the other hand, if you're doing it to make your code less sensitive to changes in the problem, or to make the implementation noticeably easier or less error prone, then it might well be worth it.
So there's your answer: is it just to be more elegant, or does it have other advantages?
这是两个正确的解决方案。
如果您确实需要担心网络流量，那么您的解决方案是可以接受的。
但您还必须记住，代码维护占据了代码生命周期的大部分时间，因此今天使代码更干净，您可能会在将来节省一些时间（已经提到过维护）。
在我看来，你应该有基于强有力的事实的充分论据来考虑此类优化。
These are two right solutions.
If you really have to worry about network traffic your solution is acceptable.
But you have also to remember that code maintenance takes the bigger part of code's lifetime, so making the code cleaner today you'll probably save some time in future (already mentioned maintenance).
In my opinion you should have good arguments founded on strong facts to think about such sort of optimizations.