xdingding  
日历
<2005年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
统计
  • 随笔 - 26
  • 文章 - 0
  • 评论 - 35
  • 引用 - 0

导航

常用链接

留言簿(11)

我参与的团队

随笔分类

随笔档案

最新随笔

搜索

  •  

积分与排名

  • 积分 - 31106
  • 排名 - 1337

最新评论

阅读排行榜

评论排行榜

 
 

GEF学习笔记(二) 模拟GEF设计思路,解剖GEF 1

 

GEF如同其他的一些framework一样,是一个复杂庞大(有点夸张)的,当我们想使用驾驭它时,就必须全面的理解其整体构架及其运作过程。这需要我们的毅力和敏锐。旅途开始了….


 

GEF主要的任务是针对2D图形编辑操作,如下图。

 

 

 

为了使GEF能够广泛的用于种类繁多2D图形编辑领域,GEF就必须建立一个严格的易扩充/易组合/易重用的MVC框架(当然这种分解细化功能对象的方法思想,我们可以用在其它的地方,其它领域、其他语言如C#上)。

 

 

 

那么如果设计 这个 严格的MVC框架(对于Model是严格的独立,它不依赖与ViewController) 以及 此框架 如何 达到 易扩充/易组合/易重用 的特性。下面我按照自己拙劣的思路,以麻雀之眼度鸿雁之志啦

 

对于MVC

View部分:GEF理所当然要使用自家的东东Draw2D。利用Draw2DFiguer作为自己的View

Model部分:往往内部包含了千差万别、不可预知的商业信息。因此、GEF框架应该尽量减少约束(在下面将详细说明约束)。

Controller部分:EditPart/Draw2DFigure/Model这三个树状对象模型,在EditPart中将建立了与其对应的Draw2DFigure/Model结点 建立一一关联的关系。

 

这样产生的构架如下:

 

 

 

 

 

 

思考:

为什么Controller要同View一样采用树状结构呢?

Controller以树状的形式存在,这样便于功能分解(这个道理有点像 在类设计中 复合优于继承 一般)

这样每一结点的Controller(EditPart) 仅需要处理

  • 自身逻辑功能
  • 管理子Controller
  • 必要时通知父Controller

尤其当用户需要在图形界面编辑界面中,需要使用多种不同UI行为规则的2D元素(例如不同的形状块,不同行为的连线等)组合来完成工作时(例如类似Visio这样的界面),这种构架的优势就显露无疑。

 

未完待续….(下面要探讨如何产生上述三个树状模型等)

posted on 2005-12-05 13:53 般若菩提 阅读(2314) 评论(0)  编辑  收藏 所属分类: GEF源码分析

只有注册用户登录后才能发表评论。


网站导航:
 
 
Copyright © 般若菩提 Powered by: 博客园 模板提供:沪江博客