用 c 封装模块的好处

用 c 来封装一个模块，可以参考下面这个连接中的做法。
http://paul.rutgers.edu/~csgates/CS416/proj2/index.html

这里的做法可以说已经到了一种极限，如果把这个 threadpool 编译为一个动态连接库的话，那么对于客户程序来说，即使在编译时使用 A 实现，在运行时改成用 B 实现也完全没问题。只要 B 实现生成的库名和 A 一致。这里关键的一点就是 threadpool 的定义，居然是 typedef 为 void *。客户程序得到的是一个 void * 指针，这样在客户程序中就完全不涉及具体的实现了。也就是常说的“对客户程序透明”（明明是 void * ，什么都没表现出来，为什么当初会使用“透明”这个词来形容，有点怪，呵呵）。这种效果已经和 cpp 中的纯虚基类的封装性差不多了，只是没有虚基类的多态功能。

这是 threadpool 的定义：

typedef void *threadpool;

threadpool create_threadpool(int num_threads_in_pool);

void dispatch(threadpool from_me, dispatch_fn dispatch_to_here,
      void *arg);

void destroy_threadpool(threadpool destroyme);

如果用 cpp 想实现类似的功能，那么就是用上面提到的纯虚基类。如果只是考虑对客户程序的封装性，那么像 c 这种全局函数可能比纯虚基类更方便。因为给纯虚基类添加一个函数可能回影响客户程序，而增加一个全局 c 函数对客户程序来说，一般不会有影响。

从长期维护的角度来说，使用 c 来做这种模块的封装还是很有好处的，甚至比 cpp 的方式更好。

评论

3 楼 Arath 2007-07-09  

这就使interface的观念

2 楼 iunknown 2007-07-07  

xombat 写道

引用

如果把这个 threadpool 编译为一个动态连接库的话，那么对于客户程序来说，即使在编译时使用 A 实现，在运行时改成用 B 实现也完全没问题。只要 B 实现生成的库名和 A 一致。

不太明白楼主的意思。

paul.rutgers.edu 的文章只是 threadpool 的接口定义，应该是 rutgers 这个学校的某个课程的一个作业题。
我的意思是说这个接口定义的做法值得学习，在某些方面有很大的好处。

xombat 写道

threadpool的那些方法他根本没有实现，只是写了一个框架而已。我认为dispatch_fn类型的函数应有由用户来完成，其它就无需用户实现了，但是他的所有方法的实现都留给了用户，每个函数中都充斥着：

// add your code here to... ... 

这里是这个接口的一个实现：http://iunknown.iteye.com/blog/38544

xombat 写道

threadpool被typedef成void *确实能隐藏一些具体实现，但是如果使用者还需要深入threadpool.c实现一部分功能，那么这个隐藏就不那么重要了。

如果按 java 的 interface 的要求来看，在 interface 是不应该体现出任何实现上的东西的。在 c 中要达到这个目标，最自然的选择就是 void * 了。这个隐藏是针对 threadpool 库的使用者，不是 threadpool 库的实现者。作为库的实现者来说，使用者对库在实现层面上的东西了解的越少越好，这样对于以后做改进比较方便。因为库的使用者只看到库的接口，不了解库的具体实现，他写的代码就只依赖于接口，这样修改具体的实现就不用担心破坏库的使用者现有的代码。

1 楼 xombat 2007-07-07  

引用

如果把这个 threadpool 编译为一个动态连接库的话，那么对于客户程序来说，即使在编译时使用 A 实现，在运行时改成用 B 实现也完全没问题。只要 B 实现生成的库名和 A 一致。

不太明白楼主的意思。

threadpool的那些方法他根本没有实现，只是写了一个框架而已。我认为dispatch_fn类型的函数应有由用户来完成，其它就无需用户实现了，但是他的所有方法的实现都留给了用户，每个函数中都充斥着：

// add your code here to... ... 

threadpool被typedef成void *确实能隐藏一些具体实现，但是如果使用者还需要深入threadpool.c实现一部分功能，那么这个隐藏就不那么重要了。