重构一个繁琐的数据结构

简介:

    在GIX4项目的开发过程中,遇到一个比较复杂的数据结构。复杂,是因为它有许多限制条件。我的工作是在现有系统中,添加新的功能,并在过程中重构部分旧代码。


约束及需求

    以下约束是系统中已经存在的必要的约束,不可绕开这些约束而进行代码的开发。

    1.项目中,有许多的实体类,都含有一种多叉树的关系和逻辑。

    2.这些实体的树型关系,在运行时,只有键的关系,而没有对应的实体引用关系。
    由于GIX4是数据分析软件,数据量比较大。建立关系需要的时间比较久,所以服务器端只负责给数据。这样客户端得到的数据,只是一个简单的对象集合。

    3.实体集合所有的更改对象位置只能使用一个特定的操作来实现排序:void Move(Object Item, Int32 index)。
    这个约束产生的主要是原因是:一:使用了CSLA作为实现分布式应用的框架,所有实体集合,都需要继承BusinessListBase。而对这个集合中的实体进行操作,经常会引起该实体的状态的改变;二:目前的OpenExpressApp框架中,要求实体直接绑定到表示层,而不能对它进行转换,如使用“ViewModel”。当然,大量的数据处理,也要求了最好不要每次都对这些数据进行转换。

    4.业务上要求,实体是可以进行排序操作的。(以下称为“逻辑序号”和“逻辑排序”。)这些序号将会持久化到数据库中。

    5.集合中的对象,应该按照“逻辑序号”进行排序。(以下称为“物理序号”和“物理排序”)

    6.树的每一个结点的孩子结点集合,也应该是按照“逻辑序号”进行物理排序。

    7.以上的操作,全部在OpenExpressApp框架中实现,而非应用层。


原有代码

    一、树的结构的定义,已经在老系统中定义并被广泛使用。属于固化因素,不可修改。定义如下:

/// <summary>
/// 树形节点
/// </summary>
public interface ITreeNode
{
    /// <summary>
    /// 所有的孩子节点
    /// </summary>
    IList<ITreeNode> ChildrenNodes { get; }
    /// <summary>
    /// 这个节点对应的父级节点
    /// </summary>
    ITreeNode ParentNode { get; set; }

    /// <summary>
    /// 当前节点的键
    /// </summary>
    object Id { get; }
    /// <summary>
    /// 父节点的键
    /// </summary>
    object Pid { get; }
}
    这个接口表示的数据结构是树的结点,但是它受到上文中第2点约束的限制:当得到一个这个接口的实例时,它的Pid有值并指示出父节点的ID值,但是同时ParentNode却可能因为没有引用到实体,而为null。同样的,虽然这个节点有许多孩子节点,但是ChildrenNodes得到的集合却有可能是空集合。

    二、实体集合对象继承自GBusinessListBase<T,C>泛型集合,对它的元素的操作只有一个:Move(C item,int index)。

 

接口定义

    在原有代码的基础上,我先增加了以下几个接口,目的在于先把复杂的概念清晰化:

ISimpleMovableCollection.cs

/// <summary>
/// 一个有简单Move操作的集合
/// </summary>
internal interface ISimpleMovableCollection : ICollection
{
    /// <summary>
    /// 把oldIndex上对应位置的元素移动到newIndex上去。
    /// 目的位置上的和中间的所有元素,都向oldIndex的方向移动一个位置。
    /// </summary>
    /// <param name="oldIndex"></param>
    /// <param name="newIndex"></param>
    void Move(int oldIndex, int newIndex);
    /// <summary>
    /// 把item移动到newIndex上去。
    /// 目的位置上的和中间的所有元素,都向oldIndex的方向移动一个位置。
    /// </summary>
    /// <param name="item">本集合中的某一个元素</param>
    /// <param name="newIndex"></param>
    void Move(object item, int newIndex);
}
internal interface ISimpleMovableCollection<T> : ISimpleMovableCollection
{
    /// <summary>
    /// 把item移动到newIndex上去。
    /// 目的位置上的和中间的所有元素,都向oldIndex的方向移动一个位置。
    /// </summary>
    /// <param name="item"></param>
    /// <param name="newIndex"></param>
    void Move(T item, int newIndex);
}

    接口中的Move方法的定义,主要是来自原系统中的方法:GBusinessListBase<T,C>.Move()。 ISimpleMovableCollection 这个集合不同于下面列出的其它集合,它并不继承自IList。这是因为它除了Move以外,没有任何别的排序操作。而如果继承自IList,则同时会拥有Insert,Remove等方法。这里需要注意的是,虽然IList接口有IsReadOnly属性来判断是否是一个只读的集合,但是如果这个值为false,而Move操作却可以执行的话,逻辑上是不对的。所以该集合直接继承自ICollection。

    泛型的ISimpleMovableCollection同样也没有实现ICollection<T>,原因也是因为泛型的ICollection<T>也有更改集合的操作。

    另外,我在这里定义的这些集合,都是一个泛型和一个非泛型配合。这是因为代码的实现是在OpenExpressApp框架中,而在框架中实体类的操作有时候是针对泛型实体,有时候却针对非泛型实体。所以这里只好也把非泛型版本也一起定义了。

 

/// <summary>
/// 有逻辑排序号的对象
/// </summary>
public interface IOrderedObject
{
    /// <summary>
    /// gs 逻辑排序号
     /// LogicIndex
    /// </summary>
    int OrderNo { get; set; }

    //event EventHandler OrderNoChanged;
}
    IOrderedObject 表示一个可以被逻辑排序的实体,可以直接设置它的逻辑排序号。这个序号也是最后会被持久化到数据库的值。这样在下次从数据库中取出时,可简单的根据逻辑号进行物理排序,减少了时间消耗。
 
 
/// <summary>
/// 按排序号OrderNo进行逻辑排序的对象集合
/// </summary>
/// <typeparam name="T"></typeparam>
public interface IOrderedObjectCollection : IList
{
    /// <summary>
    /// g 下一个新的对象,可以使用这个排序号
    /// </summary>
    int NextOrderNo { get; }

    /// <summary>
    /// 把指定的节点上/下移
    /// </summary>
    /// <param name="node"></param>
    /// <param name="isUp"></param>
    void MoveNode(IOrderedObject node, bool isUp);
    /// <summary>
    /// 按照OrderNo进行排序
    /// </summary>
    void SortByOrderNo();
    /// <summary>
    /// 按照物理位置把所有的OrderNo设置好。
    /// </summary>
    void SetOrderNoByIndex();
}
public interface IOrderedObjectCollection<T> : IOrderedObjectCollection, IList<T>
    where T : IOrderedObject
{ }
    IOrderedObjectCollection<T>表示一IOrderedObject的集合。它不但负责维护逻辑序号,也负责维护物理位置。需要注意的是,这个集合的定义,与树的操作是没有任何关系的。
 
 
/// <summary>
/// 一般的遍历类型
/// </summary>
public enum TreeNodeTravelType
{
    /// <summary>
    /// 深度优先
    /// </summary>
    DepthFirst,
    /// <summary>
    /// 广度优先
    /// </summary>
    ScopeFirst
}
/// <summary>
/// TreeNode的集合
/// 
/// 里面的元素是贫血的树节点(ITreeNode:虽然有pid,却不一定有ParentNode对象。也就是说不一定有实体引用关系……)
/// </summary>
public interface ITreeNodeCollection : IList
{
    /// <summary>
    /// 是深度排序还是广度排序
    /// </summary>
    TreeNodeTravelType SortType { get; set; }

    /// <summary>
    /// 是否集合中的TreeNode已经按照关系进行排序
    /// </summary>
    bool Sorted { get; }
    /// <summary>
    /// 是否集合中的Node都已经按照Pid关联了ParenNode和ChildrenNodes
    /// </summary>
    bool ObjectRelationsRuilt { get; }

    /// <summary>
    /// 重新建立ParenNode和ChildrenNodes关联
    /// </summary>
    void RebuildObjectRelations();
    /// <summary>
    /// 保证建立了ParenNode和ChildrenNodes关联
    /// </summary>
    void EnsureObjectRelations();

    /// <summary>
    /// 按照SortType进行排序
    /// </summary>
    void SortByTree();
    /// <summary>
    /// 保证已经排序
    /// </summary>
    void EnsureSorted();

    /// <summary>
    /// 把指定的节点升/降级
    /// </summary>
    /// <param name="node"></param>
    /// <param name="isUp"></param>
    void ChangeNodeLevel(ITreeNode node, bool isUp);
    /// <summary>
    /// 以指定的节点为位置标准,添加一个新的节点。
    /// </summary>
    /// <param name="targetNode">作为位置标准的节点</param>
    /// <param name="insertAsChild">新的节点是否是targetNode的孩子节点。(如果不是,就算兄弟/同级节点。)</param>
    /// <param name="createAsChild">
    /// 如果是添加兄弟节点,true表示放在targetNode的前面,false则表示放在后面。
    /// 如果是添加孩子节点,true表示新的节点作为第一个孩子,false表示作为第后一个绩点
    /// </param>
    /// <returns></returns>
    ITreeNode CreateNode(ITreeNode targetNode, bool createAsChild, bool beforeFirst);
    /// <summary>
    /// 把指定的节点和它所有的子节点都加入集合中。
    /// </summary>
    /// <param name="node"></param>
    void AddNode(ITreeNode node, bool recursivlyAddChildren);

    /// <summary>
    /// 在列表中查找前一个兄弟节点
    /// </summary>
    /// <param name="node"></param>
    /// <returns></returns>
    ITreeNode FindPrevSibling(ITreeNode node);
    /// <summary>
    /// 在列表中查找后一个兄弟节点
    /// </summary>
    /// <param name="node"></param>
    /// <returns></returns>
    ITreeNode FindNextSibling(ITreeNode node);
    /// <summary>
    /// 查找所有根节点(没有父亲的节点)
    /// </summary>
    /// <returns></returns>
    ITreeNode[] FindRoots();
}
public interface ITreeNodeCollection<T> : ITreeNodeCollection, IList<T>
    where T : ITreeNode
{
}

    ITreeNodeCollection<T>集合是ITreeNode的集合。类似IOrderedObjectCollection<T>,这里也与IOrderedObject没任何关系。

    这个集合中的每一个ITreeNode,都可以在这个集合中找到它的所有的关系节点。在集合里面寻找,是因为ITreeNode.ParentNode和ITreeNode.ChildrenNodes并不一定会有实体引用。 看到方法FindRoots,大家应该想到,这个集合中并不一定只包含一棵树。

 
 
/// <summary>
/// 一个元素集合
/// 
/// 整合两套不同的模式:ITreeNodeCollection和IOrderedObjectCollection
/// </summary>
public interface IOrderedTreeNodeCollection :
    ITreeNodeCollection,
    IOrderedObjectCollection,
    IList
{
    /// <summary>
    /// 按照树的顺序重新给OrderNo赋值
    /// 这里对每个根节点使用深度遍历设置OrderNo。
    /// </summary>
    void SetOrderNoByTree();
    /// <summary>
    /// 保证 逻辑Index、物理Index 相等。
    /// 并且和树的递归顺序是一样的
    /// </summary>
    void EnsureIndices();
}
public interface IOrderedTreeNodeCollection<T> :
    IOrderedTreeNodeCollection,
    ITreeNodeCollection<T>,
    IOrderedObjectCollection<T>,
    IList<T>
    where T : IOrderedObject, ITreeNode
{
}
    IOrderedTreeNodeCollection<T>才是系统中要应用到的集合。集合中的元素一定是同时实现了IOrderedObject和ITreeNode接口。所以我们可以根据树来设计逻辑序号:SetOrderNoByTree。也有了操作:EnsureIndices。


部分实现代码

    首先,有树的遍历操作,自然先实现这个。这里使用两个静态方法对已经建立关系的树进行遍历,一个深度遍历使用栈,一个广度遍历使用队列。代码就不贴了,太占空间。

image

    下面这个GBusinessTreeListBase<T,T>类,继承自原来的GBusinessListBase<T, C>类。考虑到继承层次过深对性能的影响,所以在这个类中直接全部实现了前面的所有接口。但是却是逻辑分离的。先看代码:

image

    注意到,前面的接口,继承层次是这样的:

image

    但是GBusinessTreeListBase<T,T>类在实现全部接口时,逻辑上,可以简单理解为以下形式:

image

    其中,箭头方向,即是逻辑中的继承方向,也是实现中的依赖方向。在GBusinessTreeListBase<T,T>中每一个接口实现的Region中,都可以看成是一个简单的类。只不过是把它们整合到了一个类里。如下:

ISimpleMovableCollection<C> 实现:

image

IOrderedObjectCollection<C> 实现:

image

ITreeNodeCollection<C> 实现:

image

IOrderedTreeNodeCollection<C> 实现:

image

 


后话

    细心的读者可能会发现:IOrderedObjectCollection<T>实现中的的MoveNode方法调用了IOrderedTreeNodeCollection<T>实现中的MoveNode方法;本应该出来在ITreeNodeCollection<T>实现中CreateNode方法,却被放在了IOrderedObjectCollection<T>实现。

    谁能说出这是为什么吗?这还算是单向依赖的吗?:)

目录
相关文章
|
1月前
|
存储 算法
数据结构:阶段测试(查漏补缺)
数据结构:阶段测试(查漏补缺)
36 2
|
5月前
|
自然语言处理 算法 测试技术
【数据结构原理】系统生命周期 | 算法规范 | 笔记
【数据结构原理】系统生命周期 | 算法规范 | 笔记
43 0
|
1月前
|
算法
【数据结构】复杂度学习
【数据结构】复杂度学习
|
8月前
|
存储 架构师 关系型数据库
一步步带你设计MySQL索引数据结构
MySQL的索引是一个非常重要的知识点,也基本上是面试必考的一个技术点,所以非常重要。那你了解MySQL索引的数据结构是怎么样的吗?为什么要采用这样的数据结构? 现在化身为MySQL的架构师,一步步迭代设计出MySQL的索引结构,保证你再也忘记不了索引的结构了,轻松通过面试。
|
9月前
|
算法 C++
C++基础代码--20余种数据结构和算法的实现
C++基础代码--20余种数据结构和算法的实现
109 0
|
10月前
《重构2》第八章-搬移
《重构2》第八章-搬移
85 0
|
10月前
|
存储 算法 程序员
数据结构学习分享之复杂度讲解
在我们学习完C语言的所有内容后,现在就可以开始我们的数据结构的学习,如果有读者也想走C/C++研发方向,可以跟着我一起往后学.本篇文章将收于专栏数据结构学习分享,会持续更新内容.
|
算法 Java 程序员
如何写出高性能代码(一)善用算法和数据结构
同一份逻辑,不同人的实现的代码性能会出现数量级的差异; 同一份代码,你可能微调几个字符或者某行代码的顺序,就会有数倍的性能提升;同一份代码,也可能在不同处理器上运行也会有几倍的性能差异;十倍程序员不是只存在于传说中,可能在我们的周围也比比皆是。十倍体现在程序员的方法面面,而代码性能却是其中最直观的一面。
96 0
如何写出高性能代码(一)善用算法和数据结构
|
算法 搜索推荐 Java
怎么高效的学习数据结构和算法?
怎么高效的学习数据结构和算法?
175 0
|
机器学习/深度学习 存储
重学数据结构一:代码效率优化方法论
重学数据结构一:代码效率优化方法论
72 0