所谓的model-view分离界面逻辑, 不过是一场梦而已. c++已经走到了尽头, 无损耗(性能)抽象 = 无意义抽象, 强类型 = 强迫症乐园

本来, 我打算qml一搞到底, 就这个qml, 做个编辑器, 做个编译器, 一做到底…. 但是, 最后还是放弃了….

放弃的原因, 当时是个专业原因, 简单地说就是: 松本行弘说得对, c++永远能给你惊喜. 在你难以想象的地方挖个坑把你埋了.

model-view, 不过是梦一场而已

咱们考虑一个简单的树结构投射到界面上, (树结构)是这个样子的:

"根": ["李渊", "李密"],
"李渊": ["李世民", "李元霸"],
"李世民": ["李治", "武则天"],
"武则天": ["李显", "李旦", "李重茂", "李重俊", "李隆基"]

然后此时咱们的(view核心)应该是这样的:

Text {
    text: nodeRect.modelData
}
Repeater {
    model: 树结构[nodeRect.modelData] //使用本层级的树结构数据作为模型
    delegate: view核心 // view核心递归
}

这么看上去, 简洁, 优雅, 是不是? 但是, 有没有发现一个问题, 本来就是一个简单的树结构展示, 不论是c还是python都是一个单层迭代, 但是在这里升级为一个递归迭代了, 代码中出现了一个循环调用. 也就是说一个编码问题被解决方案升级了复杂度.

这个问题相当恶劣, 用c语言两位大师的话说就是: 不必要的抽象, 人为的增加了代码编写难度.

说到这, 很多人还是会不服, 觉得这没什么, 兄弟, 这是因为现在看的是核心逻辑, 实际过程中, 在各个结构中要维护很多相关model, 比如所有的父子之间都连根线, 这个要求不过分吧? 此时要怎样? 在text的oncomplete里面要把text自身穿到某个模型里面. 然后, 在另外一个针对那个模型的响应式model-view代码里面再去做相应的连线处理. 在如此一通处理之后, 你会发现, 整体架构非常复杂, 最终结果: 除了你, 谁都改不了, 即便写注释, 写文档都没用. 这让我想起一个著名的段子.

大神哈贝内克开发codemirror时, 第一版是纯functional, 各种高阶函数, 纯副作用, 搞得飞起, 自己爽的上天了, 最后, 第二版老实放弃, 并且专门写了个js入门书(可以认为是最好的js书籍, 和js application/good part比肩).

技巧很有用, 但是如果把所有技巧都用来自虐, 那么只能说你是真的狗….

一句话总结: 世界如此艰难, 没有困难, 也要制造困难…..

放弃了… 这辈子再也不会上model - view的贼船了…