C语言中的良好设计：封装 [英] Good Design in C: Encapsulation
问题描述
只要我一直在使用C，我就已经在我的最佳封装程度上徘徊了设计。至少，我将数据
和对该数据进行操作的代码聚合成类类文件;但现在和
然后我继续使用opaque类型的兜风，并创建极简主义的标题
文件，定义非常干净的界面。
问题在于它阻止了一些优化：
*不能再在堆栈上分配结构;
*不能再将内联函数放入头文件;
*为任何数据访问提供函数调用的开销。
我很好奇C专家的感受这个设计概念;
回顾一些关于封装的旧（非常老）线程，我看到
许多人认为它好像是一些愚蠢哲学的宗旨;然而，就扩展，适应和扩展能力而言，封装对于
库的作者有各种好处。重构代码;
它还通过照亮设计帮助我完成了自己的设计
错误，然后它们变得非常远。
bluejack写道：
Ahoy：
只要我一直在使用C，我已经在我的设计中摆脱了最佳的封装程度。至少，我将数据
和对该数据进行操作的代码聚合成类类文件;但现在和
然后我继续使用opaque类型的兜风，并创建极简主义的标题
文件，定义非常干净的界面。
问题在于它阻止了一些优化：
*不能再在堆栈上分配结构;
*不能再将内联函数放入头文件;
*为任何数据访问提供函数调用的开销。
我很好奇C专家的感受这个设计概念;
回顾一些关于封装的旧（非常老）线程，我看到
许多人认为它好像是一些愚蠢哲学的宗旨;然而，就扩展，适应和扩展能力而言，封装对于
库的作者有各种好处。重构代码;
它在我自己的设计中通过照亮设计来帮助我
在它们到达之前的错误。
嗯，我是一个不透明的类型和封装风扇。我工作的最后三个大的项目使用了整个成语，每个模块都有
它自己的子目录，带有公共标题并嵌套在其中一个
私有标题和源文件的
子目录。
我看到的主要好处是开发人员的工作效率和减少的
依赖关系（往往会提高生产力） ）。能够改变
核心结构而不强制重新编译是一个很大的优势，而不是那么多在中小型项目的现代系统上的b $ b，但绝对是大的
项目以及不支持并行或
分布式建筑的旧工具链。
要支付的运行时间价格很小，但是我一直都很乐意支付。
顺便说一下，你可以通过使用
来避免动态分配结构
静态变量。
-
Ian Collins。
bluejack说：
< snip>
但现在和
然后我继续使用opaque类型兜风，并创建极简主义标题
定义非常干净的界面的文件。
问题在于它阻止了一些优化：
*不能再在堆栈上分配结构;
*不能再在头文件中放入内联函数;
*为任何数据访问提供函数调用的开销。
我很好奇C专家对这个设计概念的看法;
矛盾，这就是我倾向于在公共标题中执行此操作的原因：
#if ABANDON_OPACITY_AND_DAMN_THE_CONSEQUENCES
#include" opaquetypesinternalheader.h"
#endif
-
Richard Heathfield
Usenet是一个奇怪的地方 - dmr 29/7/1999
http://www.cpax.org.uk
电子邮件：rjh在上述域名， - www。
3月11日下午5:57，Ian Collins< ; ian-n ... @ hotmail.comwrote：
顺便说一下，你可以通过使用
static来避免动态分配结构变量。
你的意思是，预先分配源代码中的一堆结构，
还包含结构的定义？确实如此：但并不是非常可靠的某些用途，并且肯定会增加许多
环境的复杂性，尤其是多线程。
-b
Ahoy:
For as long as I''ve been using C, I''ve vacillated on the optimal
degree of encapsulation in my designs. At a minimum, I aggregate data
and code that operate on that data into classlike files; but now and
then I go on an opaque type joyride, and create minimalist header
files that define very clean interfaces.
The problem with that is that it prevents some optimizations:
* Can no longer allocate structures on the stack;
* Can no longer put inline functions in the header file;
* Incurs the overhead of a function call for any data-access.
I''m curious as to how C experts feel about this design concept;
reviewing some old (very old) threads about encapsulation, I see that
many dismiss it as though it were a tenet of some foolish philosophy;
and yet, encapsulation has all sorts of benefits to the author of
libraries in terms of the ability to extend, adapt, & refactor code;
it has also helped me in my own designs by illuminating design
mistakes before they get very far.
bluejack wrote:Ahoy:
For as long as I''ve been using C, I''ve vacillated on the optimal
degree of encapsulation in my designs. At a minimum, I aggregate data
and code that operate on that data into classlike files; but now and
then I go on an opaque type joyride, and create minimalist header
files that define very clean interfaces.
The problem with that is that it prevents some optimizations:
* Can no longer allocate structures on the stack;
* Can no longer put inline functions in the header file;
* Incurs the overhead of a function call for any data-access.
I''m curious as to how C experts feel about this design concept;
reviewing some old (very old) threads about encapsulation, I see that
many dismiss it as though it were a tenet of some foolish philosophy;
and yet, encapsulation has all sorts of benefits to the author of
libraries in terms of the ability to extend, adapt, & refactor code;
it has also helped me in my own designs by illuminating design
mistakes before they get very far.
Well I''m an opaque type and encapsulation fan. The last three largish C
projects I worked on used the idiom throughout, with each module having
its own subdirectory with the public headers and nested within that a
subdirectory for private headers and source files.
The main benefits I see are in developer productivity and reduced
dependencies (with tends to improve productivity). Being able to change
core structures without forcing a recompile is a big plus, not so much
on modern systems with small to medium projects, but definitely big
projects and on older tool chains that don''t support parallel or
distributed building.
There is a small runtime price to pay, but it has always been one I have
been happy to pay.
By the way, you can avoid dynamic allocation of structures by using
static variables.
--
Ian Collins.
bluejack said:
<snip>
but now and
then I go on an opaque type joyride, and create minimalist header
files that define very clean interfaces.
The problem with that is that it prevents some optimizations:
* Can no longer allocate structures on the stack;
* Can no longer put inline functions in the header file;
* Incurs the overhead of a function call for any data-access.
I''m curious as to how C experts feel about this design concept;Ambivalent, which is why I tend to do this in the public header:
#if ABANDON_OPACITY_AND_DAMN_THE_CONSEQUENCES
#include "opaquetypesinternalheader.h"
#endif
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Mar 11, 5:57 pm, Ian Collins <ian-n...@hotmail.comwrote:
By the way, you can avoid dynamic allocation of structures by using
static variables.You mean, "pre-allocate" a bunch of said structures in the source that
also contains the definition of the structure? True: but not terribly
practical for some uses, and would certainly add complexity to many
environments, esp. multithreaded.
-b
这篇关于C语言中的良好设计：封装的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
