20210402思考下receiver与sender的相同点于不同点 - ziyouzy/2021blog GitHub Wiki

先来看下receiver的Construct方法：

func (p *FromUSRIO808)Construct(sources net.Conn) (<-chan physicalnode.PhysicalNode, error){
    if p.Events ==nil || p.Errors ==nil || p.UniqueId ==""{
        return nil, errors.New(fmt.Sprintf("one [%s] init error, Events or Errors UniqueId is nil",p.Name()))
    }

    if sources ==nil{
        return nil, errors.New(fmt.Sprintf("one [%s] init error, Sources is nil",p.Name()))
    }else{
        p.sources =sources
    }
}

可以看到其的“一部分核心”是sourecs net.Conn，这也是所谓的数据永远，当然了，“另一方部分核心”是各个river-node有序传递所形成的链条
于是思考，会不会无论是receiver还是sender都离不开于net.Conn打交道呢？区别在于，sender的话net.Conn在参数表中就会变成Construct(fins net.Conn)了
把这大致思考了一下，似乎还是挺规范化的
不过一个receiver必须只有一个数据源，而receiver则必须只有一个数据末端这个规矩必须定下来吗？
不过似乎这个规矩你不想定也只能这样，因为无论是数据源还是数据末端，其对象实体的类型都是一个net.Conn
嗯，这个规矩至此已经定下来了，总结一下：
一个receiver必须有且只有一个net.Conn作为数据源，而receiver则必须有且只有一个net.Conn作为数据末端 同时对于receiver来说，根据实际需求可以存在多个管道形式的数据末端，而对于receiver来说则可以存在多个管道形式的数据源 但是为了逻辑的清晰应该尽量避免这种情况的发生，这种设计模式已经可以解决大部分问题了
ps：对于receiver中的数据变为events或errors是否为“多个管道形式的数据末端”的体现，答案是否定的，因为sender中的数据也会随时变为events或errors，这其实是Events模块功能机制在receiver与sender乃至整个系统中的体现

ps2：到了后期，可能会需要设计door的逻辑，比如获取发送开门指令后usrio808设备所做的反馈字节序列，那么这个序列同样会使用这个fromusrio808的receiver接收，这个数据会“混在”其他各个传感器的数据中，到时就需要把他分离出来，设计对应的管道流动分支，最终与door对接，而不再是与某个toflutter的sender对接了，所以你瞧，fromusrio808的receiver早晚会存在多个管道形式的数据末端的