最近用curl库封装了一个http请求的网络库，此网络库针对服务端来说的， 如果是封装http客户端库相对来说很简单，这里简单记录下设计思想。
1，大多数网络库的设计基本都遵循模块隔离（我称之为黑盒子）、协议分层的设计思想。网络库通过对外暴露有限的接口来接收外部逻辑的const属性参数，然后进行包装成相应的协议，最后通过网卡将二进制数据发送出去。
上图说明：
1） 数据：协议各司其职，负责自己层的数据， 不会对输入的数据进行任何修改，可以把输入的源看成带const属性的数据对象
2） 逻辑：各层负责自己的逻辑， 不应在数据对象上加上上层逻辑相关的回调，然后在下层执行回调来在赋给数据源对象（一直强调上层的数据源是const的， 增加修改上层数据的回调，协议无关性就这样被破坏了吗，没见过这样设计，%200否定， 不用也不想讨论。。。）
上图说明：
1）， 上图灰色区域即黑盒子，对外暴露的接口只有send/request接口，对应用层用户来说， 只知道如何把应用层参数填充到相关的协议， 然后调用send或request将协议push到网络库IO即可
2）， 接收到数据，调用相关的回调
HttpLib：回调通过应用层参数注册在请求对象上， 因为http请求和响应使用的都是http协议，一个请求必对应一个回复
NetIOLib：可以注册在协议对象上，也可以在初始化NetIOLib传递一个应用层持有NetIO接口的对象， 无论怎么注册，真正protocol相关最后的应用逻辑都应该在非IOThread中（除非整个进程就一个线程）
2，最后想说说设计模式的作用：
1） 解耦合
2） 高复用（插件化）
3） 高性能
4） 高灵活
5） 强伸缩
如果没有达到上述作用， 没必要强拉硬扯到设计模式上，一种优点可能会造成另一面的复杂，我们要在设计之初， 平衡到各种设计优缺点， 争取整体架构最优化