20210617关于Construct与Run的设计理念、初衷、解耦意义等

首先是提高代码可读性，不会把所有的内容放在一个函数体内，这样很不好，会变得像是小学生写的代码
然后就是最想现在探讨的，Construct是需要承担起“确保管道在刚开始运行的那一时刻”不会被以外卡住的责任
设计Construct时因为暂时并不会发生数据流动其实并不需要在意各个实体make的先后顺序，但是你需要严禁的设计好先后顺序，从而具象化严谨、优雅的设计思路
以便于日后查阅

之后基于这几个方法继续探讨：

1.tcpusrio808.sends2connRunF          	
2.tcpusrio808.conn2datesRunF
3.client.riverNodes.RunAll

3与1，2是不同的，3在执行之后并不会立刻去接收“真实的数据”，或者说，3与1，2相比，3是更容易去掌控的
从侧面上讲，3其实是作为1所描述数据流动结构的中间段（1是由流入端，中间段，流出端组合而成的）
同时3也是作为2所描述数据流动结构的中间段（2同样是由流入端，中间段，流出端组合而成的）

回看sends2connRunF与conn2datesRunF，其实只是分别对应了套接字编程的Read与Write，而套接字的底层理念之一就是底层上两者不存在任何逻辑上的先后顺序
但是由于需要心跳包这些功能逻辑，因此Read要更加重要一些，于是二者的构造与析构逻辑如下：

构造：先Read后Write
析构: 先Read后Write 

重复一遍本质上两者没有绝对的先后顺序，这里的相关逻辑并不是导致阻塞的问题的元凶

真正的元凶其实是在于sends2connRunF与conn2datesRunF内部“头与尾”初始化的先后顺序以及方式是否合理
显而易见的需要先把尾部准备好，尾部其实可以理解成中段，或者说思路上他就是中段
于是问题反而变得简单了先把client.riverNodes.RunAll与“尾”准备好，再准备好“头”（数据源，分别是p.Sends与p.tcp）
再来具象化两者各自的尾部：sends2connRunF是p.tcp，conn2datesRunF是p.Dates

真正较为复杂的逻辑其实并不是这两个闭包，而是在于闭包内部各自的handlerThread

他只需要遵循一个原则，那就是不能make任何东西，只能有效化不同类型的组件，或者说他会负责把make后的组件串联起来其外层所做的都仅仅是初始化的工作

更重要的是，确保“头”与“尾”先后顺序不出现bug，这需要他来负责