注册 登录  
 加关注

网易博客网站关停、迁移的公告:

将从2018年11月30日00:00起正式停止网易博客运营
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

为着理想勇敢前进

 
 
 

日志

 
 

庖丁解牛和架构设计  

2011-02-26 00:05:37|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

程序架构设计很像庖丁解牛。庖丁解牛的方式是“依乎天理,批大郤,导大窾,因其固然,技经肯綮之未尝,而况大軱乎!”,也就是说要顺着牛身体原本的空隙(郤、窾)入刀,而不要去砍筋骨(技经、肯綮、軱)。模块划分则要依据策划需求,以最简单正交的接口拆解模块,而不要让模块之间存在紧密耦合。二者对比如下:

庖丁解牛 要顺着天生的身体空隙下刀,而不要把筋骨人为地割开。
程序设计 要依据业务需求本质的相互关系划分简单正交的接口,而不要把紧密联系的逻辑人为地分成多个模块。

这就是庖丁解牛的独门秘笈,也是架构设计的不二标准。比如,要看 MVC 的架构是否适合本项目,就应该考察 Model、View、Controller 的分别是业务需求本身就要求的(牛本身的空隙),还是人为划分的(经脉大骨相连)。我觉得现在对那些对画面特效和交互都要求不高的游戏,其实就和做个静态网页差不多,显示(View)和领域逻辑(Model)的确是分得开的,具有天生的空隙。但凡是注重画面特效或者交互复杂的游戏,这就行不通。这种情况下,硬要套用 MVC ,有两种可能:

  1. 导致 Controller(或PureMVC 中的 Command) 急剧膨胀。
  2. 被迫把大段紧密联系的代码分到 View 和 Model 中,View 和 Model 需要频繁相互调用。如果用 PureMVC 并且又严格遵守 PureMVC 的约定的话。Proxy 和 Mediator 之间一定会有极为复杂的 Notification 结构或复杂的函数定义。根据程序设计的“实质重于形式”原则,复杂的 Notification 结构在名义上是低耦合,实质上是紧耦合。
  评论这张
 
阅读(731)| 评论(4)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018