用矩阵的概念思考图形界面的解决方案

尼克徐 发布于 2017年12月01日
无人欣赏。

从线性代数和矩阵的角度,我获得一个灵感,是关于如何操作U I界面的。

一, 图形界面的静态部分

1, 将需要显示的每个数据元素,以及相应的U I元素,组成一个对象。例如有n个这样的对象。每个对象有名字,有类型,有绑定到数据库的表的属性,有UI元素的属性等,有显示错误时提示信息的属性等。

2, 把这n个元素,排成n行1列的列向量,放在一个数组里。

3,如果这些元素间有父子关系,则用邻接矩阵的概念,来做一个连接,渲染时也会根据邻接矩阵来渲染。

4,这个列向量,其实也是一个矩阵了,里面的每一个元素,都有若干个属性,即维度。

二, 图形界面的动态部分

1, 对图形界面的所有的动作,实际上都对以上定义的那个列向量的变化,可以简化成对整个列向量的一个操作。

2,如果列向量的UI方面数值变了则更新UI,如果数值方面变了则更新到数据库。

3, 把界面上的状态变化,抽象成状态以及事件驱动下的状态转换,并写出状态转换矩阵,一切界面上的变化应该是被这个矩阵所涵盖。如果有新的需求,将修改这个状态转换矩阵。

以下是一个简单的状态机矩阵

webwxgetmsgimg.png

那么,综上,一个图形界面的解决方案如下:

第一步,定义界面矩阵

把界面上所涉及到的元素及所包含的数据,映射成一个1行n列的向量。该向量其实也就是一个矩阵,因为向量中每个元素有多个维度即属性。

第二步,定义操作符

定义若干操作符,把界面上一切变化,都反映成向量和向量经过某操作符后,被渲染的结果。

第三步,定义状态转换矩阵

如上述,需要定义出来根据事件整个界面如何变化的状态转换矩阵。

第四步,定义状态转换时所做动作

用矩阵运算的形式,来写出状态转换时所做的操作。

原则上,定义了以上两个矩阵和若干操作符,和相应矩阵操作后,这个界面的编程就告结束。

用矩阵化思维考虑UI问题时,有以下几个特征:

1, 整体化考虑,把整个界面看作整体。

2, 抽象化,一切看作向量,一切UI表现和数据表现,都是向量的呈现。

3, 界面的一切变化,都是向量变换,向量之间通过定义好的操作符的运算,转换成了新的向量并被渲染到界面上。一切以前“鸡零狗碎”的UI场景,都应该能归一到此。

用矩阵的概念想UI问题,其实是受到机器学习科目的影响。矩阵化思维减轻了思维负担。使我想起,学到解析几何后,那种通过数字机械操作就能证明出传统几何学难题的快感。

以上是一个理想化的考虑。具体如何,需实验后才知。

共5条回复
xiaotie 回复于 2017年12月01日

这个把简单问题复杂化了,gui 比这简单且更代数

尼克徐 回复于 2017年12月01日

GUI并不简单,一个简单的页面也可能有非常多而复杂的逻辑隐含其中。从界面上看不出来。而如果这些逻辑不显式表现出来,就会隐藏在深深的代码里,过些日子就是本人都不知道怎么回事。为什么前端出了这么多框架,无非是想把这个问题搞透彻。

xiaotie 回复于 2017年12月01日

2楼 @尼克徐

这走火入魔了。从两个层面看:业务层面和渲染层面。

对业务层面来说,矩阵描述的是线性变换,描述不了非线性变换(当然也不是不能描述,那就是超复杂的表达式了),而业务逻辑中,非线性的很多,直接导致这方案应用范围有限,描述能力不足。

而在 GUI的 渲染层面,那就是线性代数经典的应用啊,结构简洁、优美。

tinyfool 回复于 2017年12月01日

感觉做复杂了

尼克徐 回复于 2017年12月01日

谢谢@xiaotie @tinyfool 我还是会试试看。至少会部分采用这个方案。试过再说。

至于业务逻辑的非线性方面,至少,在状态转移这个问题上是可以用邻接矩阵描述的,哪怕嵌套多层,多层也可以平铺开。

把状态显式表达,也是我做这个事情的重要动机。一旦出问题,就可以从状态矩阵角度找到相应的点来处理。

而把状态厘清后,就剩下算法,或者有些应用就剩下增删改查了。

登录 或者 注册
相关帖子