【发布时间】:2009-10-16 09:51:49
【问题描述】:
我需要有关程序架构的良好示例和最佳实践。
我正在尝试为适用于 Google.Maps 的应用构建 JS UI。在第一稿中,用户应该能够以类似于 G.M. 的方式在地图上绘制几何形状。然后通过 AJAX 发送形状并显示响应。
问题是代码变得复杂,只是编辑多边形。
受 Joel 的“Duct-tape Programmer”的启发,我尝试编写一个简单的代码来生成操作和切换事件处理程序,以避免出现大的 if-else 树。 “新多边形”按钮为 map.onclick 创建一个观察者,更改其他按钮的事件处理程序或隐藏它们,并隐藏自身等。
这种方法的缺点是数据处理代码与接口混合在一起。创建 div 容器以在新多边形上显示数据的代码位于处理 w/ G.M 或 w/ 形状数据的代码旁边。如果我想修改 UI,我需要处理整个应用程序。
我可以稍后查看它并将这个生成 UI 的代码移到其他地方,但后来我的首席程序员来了。相反,他坚持使用“消息传递”方法:一个简单的事件系统,其中对象订阅事件并触发它们。接口代码可以与数据处理和与 G.M 对话完美隔离,但现在每个侦听器都必须仔细检查此消息是否发给它。
例如,单击地图上的多边形必须突出显示它并开始编辑。但如果正在绘制另一个多边形,则不会。所以,你在和我说话吗?代码无处不在。
我会欣赏 UI 架构方法的优秀示例。
【问题讨论】:
标签: javascript