- 主题:[供给侧]一个开源项目（xserver）18年前的一次重构 (转载)
--
FROM 1.85.202.*
函数中的“过程”被转化为了“数据结构”—— 这个很好。我一直主张这样，表达业务意义。但是cpp老鸟则认为，这样太面向对象，so boring, so java。不够cpp。
--
FROM 1.85.202.*
你说的对。
我也在尽量避免混淆，引用了其中一句，“将过程转化为数据结构”
a series of order —> data structure (and the algorithm that operates them)
data structure and its behavior ，就是我们熟悉的类的定义，也是面向对象的初衷。
我一直主张少写 series of order，多写 data structure，类名就是业务实体（概念），函数名就是业务行为（概念），加在一起就是业务模型。
如果业务对象特别复杂，可以将其单纯的定义为数据对象。再配套一个或多个handler/operator。 就是visitor模式的变形。结构和行为分离。结构稳定、行为复杂。
网上的一些cpp老鸟，认为这样太啰嗦，太java，倾向于一个函数1000行，解决问题。另一些倾向于这种做法的群体，据我观察，是下凡的科学家，自诩“我在写算法”，“这个算法模型就是有这么多变量”。我认为要么是傲慢，要么是无知。大抵是不屑于与engineer为伍的，何况code engineer，码农。
【 在 ArchLinux 的大作中提到: 】
: 这段代码是C代码而不是C++代码。
:
--
FROM 124.114.151.*
对，这样的风格很好。还有强转指针，模拟downcast的。让人可以想明白原来继承是要解决这样的问题。
语言的机制有没有是一回事，编程背后的想法（概念、逻辑、思想、哲学）是另外一回事。脑子清楚的人，写得代码不会太差。
这个重构就是做了这样的事，很小的事。但转帖的描述，“a series of order” Vs 数据结构，让我觉得道不孤，高兴之余，说两句。
另外我发现，用a series of order 的思路，来思考多线程的模型，或者co-routine，是非常好的。一个线程就是一组有序的指令，这些指令重排列，加减一点新指令，就是另一个线程。切换线程就是切换序列，线程context就是对序列的执行位置、状态的记录，对象的析构函数也是一组指令，append到序列A还是序列B，都可以（不得访问原构造序列的局部数据）。 用面向对象的思路来思考co-routine，就很阻碍。
【 在 lvsoft 的大作中提到: 】
: 这....
: 基本上所有linux下c代码都是这个风格...
: 举个例子：
: ...................
--
FROM 1.86.15.*
wayland算xserver对标物吗？我看从发起到现在的成熟度，是非常难的。
当然可能是没有金主没有动力。
当年chrome说横空出世就出世了。 火狐就稀里哗啦了…… 刚查了下，7.69%
【 在 darkk 的大作中提到: 】
: 反正我写不出来。。
: 源码有个文档的，感觉可以看一下……
: 由于需求已经梳理了，肯定比他们当年从0开始简单。。但是没有机器学习啥的，主要是熟悉各种硬件软件的接口，然后健壮性和兼容性怎么能搞好……
: ...................
--
FROM 1.80.222.*
你这个史诗级，是红军二万五千里的史诗，还是敏捷开发里的epic？
这个被把握的问题，是“Plugin”即插即用的架构设计吗？
没懂你为何这么拔高。
【 在 darkk 的大作中提到: 】
: 这里是史诗级的重构的原因在于，这次重构标志着他们对 xserver 这样子一个项目的理解接近承认，其内部的功能已经被认为是清晰的(不然无法改成数据结构)
: 这跟那种一上来先搞一套“数据结构+算法”没有太大关系。主要的意义在于面向过程和面向对象的关系如何被把握，这个被把握的问题才是“史诗级”的前提。
: 简单来说，这里体现了一种深邃的辩证法，作为结果的代码的变革的背后的思想的变化才是我评价的关键，不是设计模式的“应用”的问题，而是“设计模式”的原理的问题。
--
FROM 1.80.222.*