结合模式分离GEF的业务逻辑和视图逻辑

在前面使用GEF时，因为GEF本身就是一个MVC框架，所以“逻辑”和“视图”是分开的，比如model包中的就是逻辑，figure包里面就是视图，它们是通过EditPart作为控制器来结合起来的。
虽然这样做非常好，也是有一个小问题，那就是注意逻辑层这里，我们的逻辑类里还包含了象location:Point, size:Dimension或是constraint:Rectangle这样的定位坐标的属性。如果要使用标尺，那么还得给逻辑加上Ruler,Guide这样本身和逻辑毫无关系的类。这个弊端来自于就是我们一开始就是针对GEF来设计逻辑的。所以这种逻辑与实际中的需求可能完全是不符合的。

解决办法就将业务逻辑和视图逻辑分开，降低他们的耦合性。

方案一:
假设逻辑包:
org.rey.gef.model
里面有View,Column,Label等一些类.
我们可以新建一个包:
org.rey.gef.uimodel
里面放专门与GEF图形坐标有关的类.
比如,Node, ContainerNode.

然后可以使用继承来解决我们的问题,比如ViewContainerNode继承View和ContainerNode
ColumnNode继承Column和ColumnNode(因为使用EMF用接口来定义,所以可以继承多个接口)

方案二;
假设逻辑包:
org.rey.gef.model
里面有View,Column,Label等一些类.
我们可以新建一个包:
org.rey.gef.uimodel
里面先定义好与GEF图形坐标等有关的类,
比如:ColumnNode, ContainerNode
然后用它们到model包里的对应类的引用,(可以叫组合吧)来解决问题.

比如ColumnNode有一个到Column的引用.ContainerNode有一个到Container的引用.

显然方案二的实现要更加松耦合一些，对比两个方案的主要区别，一个使用了继承，后者使用了组合，又一个很典型的例子----“组合优先于继承”

例如我的逻辑UML图如下:
左半部分是业务逻辑，和图形没有任何关系.
右半部分是图形逻辑，和GEF有关,通过组合结合起来。




文章标题是说结合模式，这里Node和MultiNode就使用了Composite Pattern.

编辑Model的editor(就是自动生成的EMF editor):


最后是GEF editor:


References:
<<IBM Red Book:Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework >>
Logic Example
Gef学习教程 Unplugged版