20210318关于当前思路，对于physicalnode模块的分层 - ziyouzy/2021blog GitHub Wiki

问题有些棘手，直接进入正题：
1:最外层：river-node.physicalnode层
2:向内一层：raw->physical转换层
3:再向内一层：此层来实现physical去调用protocol
ps:最最外层river-node.physicalnode所在的river层(或许会继承心跳包river-node)

第一个大问题是，“1”拥有Events与Errors这两个整体框架所必须的核心组件，是否要对其进行某种意义上的“依赖注入”，如：

type PhysicalNodes struct{
   UniqueId string
   Events chan rn.Event 
   Errors chan error

   Raws chan []byte	
   News chan physical.Physical

   stop chan struct{}
}

func (p *PhysicalNodes)newPhysicalNodeFromBytes(raw []byte){
    res := bytes.Split(raw, split)
UpStreamUniqueId :=string(res[0])
ConType :=string(res[1])
HandlerHex := hex.EncodeToString(res[3][:7])/*诸如：49 4f 30 31 f1 01 01共七位，用它来判断具体属于DO还是DI*/
TimeStamp := res[2]//让他保持[]byte的状态

    protocol20210318_GUANGYI_LTD_BASIC_v001(UpStreamUniqueId, ConType, HandlerHex, TimeStamp，raw,p.Events，p.Errors)
}

由此可见对于river-node.PhysicalNodes与单纯的PhysicalNode是否融合，这个问题的核心在于newPhysicalNodeFromBytes这个函数是否独立
如果不独立的弊端在于NewPhysicalNodeFromBytes(raw []byte，,p.Events，p.Errors)，也就是说这一层很可能也需要进行依赖注入

或者说无论是哪一层，层与层是否融合的区别都是在于p.Events，p.Errors的依赖注入问题

第一层与第二层之间，应该设计成单纯PhysicalNode模式与river.PhysicalNodes模式的双模式都可以用
而对于Protocol层，如果希望他独立，那就应该独立的更彻底一些，让他直接变成一个与river-node一样独立的包

目前更倾向于取消独立的“NewPhysicalNodeFromBytes”模式，因为无法融入Events与Errors逻辑结构
仔细想想，旧时的框架设计模式其实是用结果类内部是否为空来分别表达正确/错误，而现在的框架设计模式则是用nil/error/event来分别表达正确/错误/不完美
这是问题的根源，我现在是在尝试将旧框架设计模式与新框架设计模式对接，而不是用新框架取代旧框架