以下是一段我的实际代码过程和思考纠结过程：
//抽象业务逻辑执行线程
void * vertical_bhos (void * arg) {pthread_detach(pthread_self());
//业务线程，暂时想不出如何单独另外建立业务类。。。 //直接线程完事？？？不行。。。行。。。 //仍然建议高层业务逻辑使用类，大不了传入多个底层类抽象引用呗。。。 //(但如此违背了最小知道原则？业务逻辑类也不能知道？？？理解有问题吧？) //业务逻辑最终还是没成类，而是成了线程，此线程代表抽象业务逻辑，由此接口目前还是没有用到，直接指定了所有类和对象。 //小失败，还得继续改。。。 AGENT * thread_agent = (AGENT *)arg; printf("vertical_bhos thread init\r\n"); ppositionClass pre_obj(v_position_file); ppositionClass & pre = pre_obj; if(0 != access(v_position_file,0))//检查文件是否存在,不存在就创建 { printf("init pre file\r\n"); pre_obj.pposition_init(); } ctlsequenceClass ctl_obj(38400,"/dev/ttySP0"); ctl_obj.serial_open(); ctlsequenceClass & ctl = ctl_obj; sharemodeClass share_obj(ctl); sharemodeClass & share = share_obj; CHECK check_obj(ctl,share,thread_agent); MOVE move_obj(ctl,share,pre,thread_agent); sleep(1); while(1) { run_ret = SUCCESS; 类似这样，有些逻辑是控制对象的，这些在对象看来时外露逻辑， ///一旦有这些逻辑很蛋疼，一旦这些逻辑负载重就跟蛋疼 //一旦这些逻辑复杂了，就说明设计出问题了， //要么逻辑下下压给被控制对象，要么控制逻辑上浮成新对象。 //这就是典型的会遇到的问题 // // //但是目前问题是，这些复杂的逻辑关系始终理不清楚。没法良好的 //分层理清，是否说明： //抽象有问题 //分层有问题 if(0 == thread_agent->do_you_have_new_cmd(&temp_cmd))
{
总结：
有时候对象之间就是有复杂逻辑联系，浮不上也压不下，这层逻辑给谁都感觉不行，这层耦合怎么处理似乎都松不了。
后来才发现，而且原来还是“行为模式”来定义、关注、处理这种复杂联系。
优化：我使用了其中最简单的一种优化方式:直接新建一个“独立处理互动复杂逻辑关系”的对象。
//互动关系独立对象的优势在于，可以将原本分散于各自对象的逻辑分离到新的专属对象中， //虽然在物理位置上看来，并没有分离，荏苒分散在各自的对象中，但其实，新对象的存在 //可以使得原来处于各自对象中的分散的、具体的，逻辑关系抽象接口化、集中化，这就是优势， //关键就是可以抽象化的这个优势，一旦可以抽象化就能降低耦合。。。 //一定要注意互动独立对象要在原来各自的对象体中体现出封装性，不能暴露出互动对象体的内部逻辑 //以前一直不明白封装的作用，现在有点眉目了，对外封装的好处在于减少逻辑外露，这样才能 //良好的能把项目持续下去，否则会由于逻辑过多直接无法持续下去了。 //优先显示开始： //原来通讯中转动命令是同一个VELC，一开始一个比较便利，但后期开始不足， //所以需要将VELC扩展成VELC_CLOCKWISE和VELC_UNCLOCKWISE,这时就会发现 //如果没有”互动关系独立对象“，那么就会导致两边对象的大量改动，特别时涉及到 //逻辑的那种改动就特别要命，但是现在使用”互动关系独立对象“+“配合原两边对象中的抽象接口” //那么，“配合原两边对象中的抽象接口”由于是深入到对象中去的，可能需要改动，但 //由于抽象的存在，改动肯定不大（否则就是抽象接口设计问题了），而将改动的重点移到了”互动关系独立对象“内部。 //这个内部的独立改动时轻松的。 //优势显示出来了吧。
