构建通用类型- 继承 VS 聚合
【问题】
在CAD或画图软件设计设计中,会存在大量的基本体[2],如line、 circle、arc、 polyline、 sphere、 box等。在组织它们之间的关系的时候,一般会有如下的继承体系:
图表 1 基本体类结构
即对每一种基本体,都有一个class与之对应。若有100种基本体,那就得有100个class从Entity继承而来。
但从这些class本身来看,问题并没有多么严重,毕竟不同的基本体总得有个class或object异或别的什么东西与之对应。一个完整的画图软件总得有序列化机制、总得有个undo/redo机制、总得有个界面显示这些纷纷乱乱的基本体的参数以供交互式操作吧。因此,每个类又得加入save/load操作,undo/redo支持,再加上套UI class[3]。记得N年前做的一个CAX项目中,但为基本体写UI class就花了2W行代码,现在想想有些汗颜。
图表 2 属性类与基本体类关系
图表 3 CAD示例
在写了N多相似的类后未免让人厌倦,让人有种重构的冲动。实现界面与数据分离可以使用脚本的办法,在此不作赘述。
【解决方案】
对于一个绘图程序,其基本体主要有两部分内容:参数 + 构建方法。各种基本体之间的差异也存在于此。数据部分可以用一个variant[4]容器统一来描述,通过一个参数ID提取不同的参数。差异最大在于创建实体的方法,即作用于参数的行为。再次抽象后,通用基本体类型层次关系如下:
图表 4 通用基本体类型类结构
各种基本体类型都用Primitive统一描述,不再从它继承子类,而是实现不同的创建基本体的BuildMethod。最后用一个Factory模式管理各种BuildMethod,根据与Primitive绑定的BuildMethod ID,创建几何形状。
由此所带来的好处是:
1. Save/Load只需要在Primitive实现
2. Undo/Redo只需要在Primitive实现
3. 可以从Primitive的参数类型描述中提出GUI表现形式[5]
4. 可扩展性得到增强,新增的类型无需考虑以上三条。
由此所带来最大的坏处就是性能上有所损失。从variant得到具体的数据类型毕竟没有直接用原始的数据类型来的高效些。从使用的效果来看,并不会产生用户交互上的延迟。
【总结】
前后两种方法的主要差别在于是使用继承还是聚合,以及是如何使用继承的。二者本身没有优劣之分,但在具体的情景下就需要权衡利弊。
--- 力为
[1] 《设计模式》
[2] 指基本几何类型。不知道这世界上有多少基本体,在不同的领域中可能基本体的定义也不尽相同。建筑中,可能门,窗都算作是基本体。
[3] boost::serialization 提供了一种非侵入式的序列化方法,值得一试。
Undo/redo的实现可以参考GoF的Memento Pattern.
[4] variant的实现有多种方法,boost有两种,参考boost::any 与 boost::variant 的区别。
[5] 提取形式亦可参考如何从脚本提取UI的实现方法。