基于多继承的树设计

分类

 

树是一种常见的 ui 组件，在桌面以及 web 中都经常看到，常见的表现形式有

 

简单树：

 

 

多选树：

 

 

如何设计？

 

针对树的两种主要分类，这次主要讨论 DRY ，怎么能把重复的功能拆成独立的单元而最终又能完美的整合？我的答案是多继承:

 

 

 

组成部分

 

BaseNode : 最基本的树节点，类似 dom 树节点，记录该节点的子节点和父节点，可以添加删除子节点以及特有的选中操作，展开和收缩操作。具体通过onClick来响应用户点击。

 

 

CheckNode: 继承自 BaseNode，但是可以记录更多的选中状态和展现形式：子节点和自身都选中（fullCheck），子节点没有全部选中（partCheck），子节点和自身都没选中（none）。具体通过覆盖 BaseNode 的 onClick 响应用户点击来设置状态.

 

TreeEvtDelegate: 功能类，用于事件代理，可代理树根节点下的所有子节点的事件并在合适的子节点上执行对应的事件处理器

 

TreeStateMgr : 功能类，缓存树根节点的所有子节点，便于快速获取，以及记录树级别的状态：树的当前选择元素集合，树是否显示根节点，...

 

Tree: 简单树，实际上用继承于普通节点的根节点来表示一棵树，只不过它可以代理子节点的事件（具体参考事件代理的好处）以及具备树节点的一些全局状态.

 

CheckTree：同 Tree 类似，只不过它通过继承 CheckTree 可以具备更多的状态。

 

 

最后通过多继承， Tree 以及 CheckTree 的功能完全分散到抽象父类上并可以完全互相共享，树本身只是一个空壳（命名） 而已。

 

 

 

对多继承的想法

 

Tree 包括基础框架以及其他一些组件已经完成不少时间了，但也在一直犹豫，多继承是否合适，是否会加剧复杂化，能否在未来多变的需求下易于维护，但感谢《松本行弘的程序世界》，书中 ruby 发明人详细讨论了多继承，解释了为何动态语言中的 mixin 是一种可控，切实的多继承方式，那么如果再进一步增强对功能类初始化过程的控制，也就具备了更强的表达能力，这很可能就是未来的趋势.