【Seago.】UI系列教程（四）——初期总结

本篇是对前几篇的内容进行总结与一定的补充扩展。主要还是针对Jass方向的作者，T不便于设计，但也可参考思想。

前几篇算是比较基础的认知，主要解决了UI的创建问题。核心思想就是“树形的层次结构”，即一组基本的UI控件，应该搞清楚他们内在的关系与联系，而不是简单的只当作孤立的个体拿去拼凑。
为什么一定要强调这一点，最基本的目的就是为方便封装。
封装并不是表面看上去那么简单，把一堆操作都放在一个函数里，这种观点太狭隘了。就像做菜一样，正经做菜不同的菜有不同的做法，放什么材料都是有讲究的。去饭店里点菜，都是一份一份分开上的，哪有所有菜都混在一起一锅上的？
就如讲相对位置时的一句话，一定要弄清楚其中的因果关系——因为这些操作之间彼此有关联，他们共同在干一件事情，所以我们把他们放在一起，封装成了统一的函数，这样的操作恰好也可以为我们提供便利。而不是为了省事，所以不经分析就把所有的东西都放在一起。这也就体现了软件工程中常说的一句话“高内聚，低耦合”。通俗点来理解，就是功能是否便于移植和维护。我们有逻辑地将相关联的操作封装在一起，他们共同为一件事而工作，则我们的修改也将是纯粹的，因为产生的影响也始终是必要、可控的。而如果只是笼统地把所有东西都混合在一起，那么极有可能他们之间本没有任何联系，一旦发生修改则容易导致不必要的bug。
当我们将一套复杂的UI设计成一个层次分明的树结构时，则很容易理清他们之间的关联关系，从而方便我们进行不同程度的封装。而如果只是停留在单薄的平面结构，那么所有的UI都是孤立的，则很难去划分他们之间的关系。
当然，理论都是趋近完美的，实际操作总有不可预计的意外。我们不可能完全按照理论的假设去设计出一套万能的系统，难免有一些不得已得取舍，这是必然。在需要取舍时，具体孰轻孰重则需要作者结合实际情况以及自己的能力再进行抉择了。

UI的存取
这也是一个比较常见的问题，也是强调上一点的另一个原因。
一旦开始使用UI，通常都会创建大量的UI，而不是简单的只是一两个，这时存取问题就很重要。见过比较多的是使用数组进行存取。数组的好处是不需要创建太多的全局变量，不至于看起来很乱。当然坏处也很明显，数组的索引都是整数，后期很容易忘记哪个整数代表哪个UI，或者因为自己的计算失误，导致取错了UI，排查起来也很麻烦。
我的解决措施是结合设计的树形层次结构进行UI的关系记录。
前面的教程有提过，UI在代码中的本质其实是以整数的形式存在的，记录的是其在内存中的地址。而只要是整数，我们都可以结合哈希表来进行操作（可见哈希表实在是个好东西）。对于每一个UI，都可以作为哈希表的主索引，而次索引可以用来表示他与目标UI之间的关联关系，值则记录目标UI。这样，对于每一个功能模块而言，我们只需要专门记录一个UI即可，其余的所有UI都可以通过关联关系进行查找获取，这就和我们的树形结构对应上了。而关联关系虽然也是整数记录的，但通常不会太多，因为大部分复合UI，他们控件之间的关系都具有相似性，完全可以加以总结并进行设计，限制在有限的范围内。而不会像数组的索引那样，随着UI数量的增加而不断膨胀最终不可控。并且数组的上限只有8000多，而哈希表的索引空间理论上对于一场游戏而言是根本用不完的，用于记录每个UI之间的关系绰绰有余。

游客，如果您要查看本帖隐藏内容请回复

感谢大佬分享

感谢分享

谢谢大佬

好东西 支持

感谢分享

感谢大佬教程

感谢大佬分享

感谢大佬分享