封装太多了? [英] Too much encapsulation?

查看:74
本文介绍了封装太多了?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近读过你想知道的有关C类型的所有信息。通过

Peter Seebach(1),了解了不完整的类型。现在,我意识到了封装的

值,但是我想知道使用

这是不是很合适的C风格。通过使用不完整的类型,你最终得到类似

这样的东西:


object_set_colour(object,RED);

color = object_get_colour (对象);


而不是:


object-> color = RED;

color = object - >颜色;


如果类型为对象是不完整的,你不能写对象 - >颜色或

之类的东西,因为访问不完整类型的数据不是可能的b $ b。只有包含get / set rountines的文件定义了

类型。你最终得到的东西看起来非常像OOP +可怕的
开销。请记住,您需要在单独的文件中保留get / set函数+

实际类型定义以获得封装效果。

这意味着没有主流C编译器将能够优化那些

函数调用(AFAIK既不是GNU,也不是MS,也不是Borland可以从其他文件内联

函数)。


所以你认为适当的C风格吗?

就个人而言,我不知道该怎么想。它似乎尖叫为什么

你还没有使用C ++?!。


链接:
http://www-128.ibm.com/developerwork...&Search=Search

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colour(object, RED);
colour = object_get_colour(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

So do you consider that proper C style?
Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Link:
http://www-128.ibm.com/developerwork...&Search=Search

推荐答案

6月14日下午3:28,copx < c ... @ gazeta.plwrote:
On Jun 14, 3:28 pm, "copx" <c...@gazeta.plwrote:

我最近读过你想知道的有关C类型的所有内容通过

Peter Seebach(1),了解了不完整的类型。现在,我意识到了封装的

值,但是我想知道使用

这是不是很合适的C风格。通过使用不完整的类型,你最终得到类似

这样的东西:


object_set_colour(object,RED);

color = object_get_colour (对象);


而不是:


object-> color = RED;

color = object - >颜色;


如果类型为对象是不完整的,你不能写对象 - >颜色或

之类的东西,因为访问不完整类型的数据不是可能的b $ b。只有包含get / set rountines的文件定义了

类型。你最终得到的东西看起来非常像OOP +可怕的
开销。请记住,您需要在单独的文件中保留get / set函数+

实际类型定义以获得封装效果。

这意味着没有主流C编译器将能够优化那些

函数调用(AFAIK既不是GNU,也不是MS,也不是Borland可以内联

函数来自其他文件)。
I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colour(object, RED);
colour = object_get_colour(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).



MS VC ++可以做到这一点。

如果你做了俗气,那么所有人都可以做到这一点:


/ * main.c从这里开始...... * /

#include" file1.c"

#include" file2 .c"

#include" file3.c"

#include" file4.c"

#include" file5.c" ;

int main(无效)

{

返回some_important_function();

}

/ * main.c在这里结束...... * /

MS VC++ can do it.
And if you do the cheesy, sleezy include trick all of them can do it:

/* main.c starts here... */
#include "file1.c"
#include "file2.c"
#include "file3.c"
#include "file4.c"
#include "file5.c"
int main(void)
{
return some_important_function();
}
/* main.c ends here... */


所以你认为那个合适的C风格吗?

就个人而言,我不知道该怎么想。它似乎尖叫为什么

你还没有使用C ++?!。


链接: http://www-128.ibm.com/developerwork...lts.jsp?search ...
So do you consider that proper C style?
Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Link:http://www-128.ibm.com/developerwork...lts.jsp?search...



如果我想要C ++,那么我用C ++编写代码。


如果我想写一个Unix风格的过滤器,我将使用C.


另一方面,我没有问题阅读甚至享受C代码

用C ++风格编写。


另一方面,另一方面,我已经看到了所有内容的程序

typedef-ed成某种抽象类型(甚至像循环索引之类的东西)和

发现这些程序的理解要比

更简单易懂。


IMO-YMMV。

If I want C++, then I code in C++.

If I want to write a Unix style filter, I will use C.

On the other hand, I have no problem reading or even enjoying C code
written in a C++ style.

On the other, other hand, I have seen programs where everything is
typedef-ed into some abstract type (even things like loop indexes) and
find those programs to be a lot less transparent to understand than
one more simply written.

IMO-YMMV.


" copx" < co ** @ gazeta.plwrites:
"copx" <co**@gazeta.plwrites:

我最近读过你想知道的有关C类型的所有内容通过

Peter Seebach(1),了解了不完整的类型。现在,我意识到了封装的

值,但是我想知道使用

这是不是很合适的C风格。通过使用不完整的类型,你最终得到类似

这样的东西:


object_set_colour(object,RED);

color = object_get_colour (宾语);
I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colour(object, RED);
colour = object_get_colour(object);



如果你最终得到这个,你真的没有*任何封装。

你所做的一切都发明了新的语法:

If you end up with this you don''t really *have* any encapsulation.
All you''ve done invent new syntax for:


而不是:


object-> color = RED;

color = object-> color;
instead of:

object->colour = RED;
colour = object->colour;



你已经发现了。


不完整的类型在你拥有的界面时最有用
$与隐藏在其后面的实现的复杂性(或可能的

可变性)相比,定义的b $ b很小。


-

Ben。

as you have spotted.

Incomplete types are at their most useful when the interface you have
to define is small compared to the complexity (or probable
variability) of the implementation that is hidden behind it.

--
Ben.


copx写道:
copx wrote:

我最近读过你曾经做过的一切想知道C类型通过

Peter Seebach(1),了解了不完整的类型。现在,我意识到了封装的

值,但是我想知道使用

这是不是很合适的C风格。通过使用不完整的类型,你最终得到类似

这样的东西:


object_set_colour(object,RED);

color = object_get_colour (对象);


而不是:


object-> color = RED;

color = object - >颜色;


如果类型为对象是不完整的,你不能写对象 - >颜色或

之类的东西,因为访问不完整类型的数据不是可能的b $ b。只有包含get / set rountines的文件定义了

类型。你最终得到的东西看起来非常像OOP +可怕的
开销。请记住,您需要在单独的文件中保留get / set函数+

实际类型定义以获得封装效果。

这意味着没有主流C编译器将能够优化那些

函数调用(AFAIK既不是GNU,也不是MS,也不是Borland可以从其他文件内联

函数)。


所以你认为适当的C风格?
I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colour(object, RED);
colour = object_get_colour(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

So do you consider that proper C style?



是的,这是一个非常常见的习惯用法(你有没有操纵过一个文件

对象?)。有时您希望使用封装在多个平台上呈现

一致的界面。其他时候你可能希望为你的应用程序版本之间的某个对象提供一个稳定的界面,这个界面可能会发生变化。

Yes, and it''s a very common idiom (have you ever manipulated a FILE
object?). Sometimes you want to use encapsulation to present a
consistent interface over a number of platforms. Other times you may
wish to provide a stable interface to an object that is liable to change
between releases of you application.


就个人而言,我不知道该怎么想。它似乎尖叫为什么

你还没有使用C ++?!
Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".



与C ++无关,除非你正在使用类似的成语和不透明的

类型,C ++类的内容让所有人都看不到。


-

伊恩柯林斯。

Nothing to do with C++, unless you are using a similar idiom with opaque
types, C++ classes lay their innards bare for all to see.

--
Ian Collins.


这篇关于封装太多了?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆