程序接受串口的pelco协议，根据协议类型(a,b,c...)，作成if分支，分支中将分析出的命令插入同一个队列中去。此时结构合理简单，但是一般不会这么便宜你，都会存在附加逻辑，a，b，c型命令只有在队列数据量分别少于2，3，4时插入。
流程化语言可能习惯性这么做：
1：先判断pelco的协议分支
2：进分支后判断当前队列的数据量，
3：对于某些信息可存三条，某些信息存两条。
4：此时需求有改变，当队列中全部是b型数据时，a也可以再插入一次，
5：好。按照要求改好了。。。
目前这样也可以运行，但是发现流程化的行为使得在判断数据是否插入时，造成了逻辑固化！因为有些要求是后期增加的，一旦增加，那么对原来的逻辑流程会在一些地方做出所谓的“特殊条件处理”，这是我常常遇到的状态！
这种常出现的“特殊条件处理”需求会导致程序存在未知bug点，更增加了程序的再次阅读难度，浪费脑细胞。
以下是我当时面对这个问题时的暂时思路过程：
//我将这种亲情况归纳：称这是种逻辑节点的处理问题。这个问题可以有oop来清晰化流程导致的逻辑固化，于是有了如下的想法。
//1：目前是本能习惯性，放在目前这样的位置直接流程化处理，这肯定不合适
//2：打算交给queue对象处理，逻辑关系交给queue对象
//再思考，为什么这里会出现这种逻辑固化，又需要如何使用oop处理。
//1：问题在于：此处的逻辑分析判断并不是简单的if(1)...else...，分支判断不是bool型，而是int多数值型。
//2：问题在于：全局式的变量作为多处逻辑分支使用，且还不是bool型时，都容易出现这种逻辑固化的状态。
//3：问题似乎有点棘手，有点深了。
//再再思考：
//这是个 “逻辑点” 的归属问题，首先应该判断这个逻辑判断应该属于queue还是pelco。
//说白了，就是这个逻辑该由那个对象来判断处理。
//应该将全局的非bool分支判断变量局部化、或者bool化。
//这在设计初期需要合适的思考，这样能够清晰程序，而不是导致逻辑混乱
//得出结论：
//这里的分支判断对象不应该是queue的逻辑，而是pelco的逻辑业务
//pelco的解析，应作为对象化处理
//再次发现存在问题：
//业务逻辑虽然明显来说属于pelco的，但是处理这个业务逻辑时，严重需要依赖queue对象，难道该逻辑又属于queue？
//再得结论：
//这种依赖是正常对象间的依赖，而不是仅仅这也问题业务逻辑导致的依赖。
//pelco想要的是queue对象的当前队列数据量，来决定是否通知队列对象插数据，
//而不是queue判断当前pelco的数据队列，来判断是否插入pelco的数据队列，
//这判断方式会导致queue对象吃进了pelco的业务，queue不再纯洁，
//pelco对象是开行了，但是别的"想要"queue的对象就不喜欢了。
总结：
1：当流程需求多变，要使用oop形式。
2：当出现逻辑分支点，要思考这个逻辑应该是谁的，并且深深藏好，不能暴露。
3：对象之间的“依赖”普遍存在，但是应该是抽象型依赖，不能具体化，这同样需要归纳思考。