Rectangle：struct还是class？ [英] Rectangle: struct or class?
问题描述
下面的内容可能会让你们中的许多人感到愚蠢，但它代表了我在尝试制作设计时发现自己的那种删除行为的b / b
决定。这是一个为了学习使用C ++而学习的玩具项目。因此，对于我来说，给出
情况下面给出的考虑金额是有道理的。说实话，
我很惊讶这个看似简单的
情况的数量。
我正在努力学习使用C ++，就像Stroustrup在TC ++（PL）中告诉我们的那样。
他有一些不同的指导方针可以确定是否应该是什么。
被视为一个类或一个结构（在''C'意义上）。一个衡量标准是
它是否具有需要保留的不变量。所以，假设我有一个矩形
{x，y，w，h}其中x和y是左上角的坐标，并且w
和h是宽度和高度分别。我可以随意更改该组中的任何元素，并且仍然有一个矩形（假设w> 0，h> 0，或者我将
赋予替代方案的含义） 。他的另一个标准是，是否有两个可能的同一抽象表示形式。如果是这样的话，它就是b $ b认为它应该是一个类我要说是的。
struct Rectangle {size_t x，y，w，h;} ;
struct Point {size_t x，y;};
struct RectanglePts {Point xy，dxdy;}
我可以还想要一些便利功能，比如
矩形& Rectangle :: widen（const size_t dw）{this-> w + = dw;归还这个; }
矩形& Rectangle :: move（const Point dxy）{
this-> x + = dxy.x;
this-> y + = dxy.y;
返回此; }
有趣的是，有一个操作，当一个不变量可以确定为
时。 Rectangle :: xy和Rectangle :: dxdy
之间的位移应保留在翻译下。同样，缩放操作应该保持两边长度之间的比例。
然后我问Rectangle是否应该从Point派生。
的论据要么是选择。他建议提出这样一个问题：这个对象有两个可以作为基类的东西吗？起初我可能会说
是，我可以有两点以上。我只需要两个点来定义矩形的
。这就是说矩形应该有Point成员，
而不是Point。但是，如果我们说一点不仅仅是一个点，那么它就是一个位置。所以我们再问一遍，它可以有两个吗？。嗯，是的，没有。
它可以有很多位置。在数学上，矩形中有一个
无限多个点。但矩形作为一个整体
实际上只有一个位置。
将矩形视为具有大小和
形状。我们可能会将它视为几何对象，而不是将Point视为一对坐标或
位置。可以将
视为基本几何对象。我们绝不会在没有位置的情况下在屏幕上绘制
几何对象。我可以使用
相同的一组操作来移动任何几何对象，因为我用来移动一个
点。我甚至可以编写一些操作符来添加两个点作为向量，然后
然后在其他几何对象中继承它们。如果我将一个Point添加到
矩形，则相当于移动rectangel，使得左上角的
坐标具有添加的点的组件
给他们。
我还没有完全明确的测试来确定一个矩形
应该是一个类还是一个结构。我也无法明确决定它是否应该是一个点，并有另一个点，或者它应该有两个点。由于涉及定位的原因，我赞成
前者。
但现在，我必须考虑一点。它可以有两个表示吗？一个
愚蠢的{x，y} odered对？对！ {r cos（theta），r sin（theta）}。我甚至
简单地接受了从std :: complex继承我的
Point类的想法。
但它是不是一类？它似乎没有任何其他不变量而不是它有两个组件。但是/ /是一个在创建
对象时确定的不变量。但是对于任何有两个成员的结构都是如此。
那么保护Point组件的优势是什么？一个论点
人们给出的是它可以防止我无意中修改数据。
在这种情况下，这似乎有点虚假。 Stroustrup没有提到的另一个更合理的b $ b参数是事件
通知的概念。如果我在Point上更改了一个值，我可能想要通知
图形渲染软件，以便它可以安排更新。如果
我调用了一个方法来进行更改，我可以将事件作为一个方面触发
效果。
所以我使组件受到保护。所以呢？我花了多少剂量？
我在Rectangle中继承的点就像我想要的那样。它从我需要它的所有点继承了
。 OTOH，当我尝试修改右下角dxdy的
组件时，我发现我不允许
访问受保护的数据。所以，要么我使用公共接口来修改数据，要么使用矩形或某些独立函数作为Point的朋友。
前者是循环引用，不好设计，作为一般规则。
后者是我觉得味道不好的东西。
如果我的公共界面设计得很好，那就写下额外的
Rectangle中的
代码没什么大不了的。我还会考虑最后一个因素，我真的不知道答案是什么。一个体面的
编译器（在我的例子中是g ++）优化掉函数调用，例如：
Point< T>& operator + =（const Point& p）
{
this-> x + = px;
this-> y + = py ;
返回*这个;
}
？
-
STH
哈顿定律：只有一个不可侵犯的法律
KDevelop： http://www.kdevelop.org SuSE： http://www.suse.com
Mozilla： http ：//www.mozilla.org
The following may strike many of you as just plain silly, but it represents
the kind of delelima I find myself in when trying to make a design
decision. This really is a toy project written for the purpose of learning
to work with C++. It therefore makes some sense for me to give the
situation the amount of consideration presented below. To be quite honest,
I''m amazed at the amount there is to say about such a seemingly simple
situation.
I''m trying to learn to use C++ the way Stroustrup tells us to in TC++(PL).
He has a few different guidelines for determining if something should be
treated as a class or a struct (in the ''C'' sense). One measure is whether
it has an invariant that needs to be preserved. So, say I have a rectangle
{x,y,w,h} where x and y are the coordinates of the top left corner, and w
and h are width and height respectively. I can arbitrarily change any
element of that set and still have a rectangle (assuming w > 0, h > 0, or I
assign meaning to the alternatives). Another criteria he has is whether
there are two possible representations of the same abstraction. If so, it
argues that it should be a class To that I say yes.
struct Rectangle{size_t x, y, w, h;};
struct Point{size_t x,y;};
struct RectanglePts{Point xy, dxdy;}
I may also want some convenience functions such as
Rectangle& Rectangle::widen(const size_t dw){ this->w += dw; return this; }
Rectangle& Rectangle::move(const Point dxy){
this->x += dxy.x;
this->y += dxy.y;
return this; }
Interestingly, there is an operation for which when an invariant can be
identified. The displacement between Rectangle::xy and Rectangle::dxdy
should be preserved under translations. Likewise scale operations should
preserve the ratio between the lengths of the sides.
Then I ask if Rectangle should derive from Point. There are arguments for
either choice. He suggests asking the question "can the object have two of
the things you are considering as a base class". At first I might say
"yes", I can have more than two points. I only need two points to define
the rectangle. That argues that the Rectangle should have Point members,
rather than be a Point. But what if we say a point isn''t just a point,
it''s a location. So we ask again, "can it have two?". Well, yes and no.
It can have many locations within it. Mathematically, there are an
infinite number of points in a rectangle. But the rectangle as a whole
only realistically has one position.
And it makes some sense to treat the rectangle as a position with a size and
shape. Rather than thinking of a Point as a pair of coordinates, or a
location, we might think of it as a geometric object. It could be
considered as the fundamental geometric object. We will never draw a
geometric object on a screen without it having a location. I can use the
same set of operations to move any geometric object, as I use to move a
point. I might even write some operators to add two points as vectors, and
then inherit these in other geometric objects. If I add a Point to a
rectangle it is equivalent to moving the rectangel such that the
coordinates of the top left corner have the components of the point added
to them.
I have not completely definitive test to determine whether a rectangle
should be a class or a struct. Nor can I clearly decide if it should be a
Point and have another Point, or if it should have two points. I favor the
former for the reasons involving positioning.
But now, I have to consider a point. Can it have two representations? A
stupid {x,y} odered pair? Yup! {r cos(theta), r sin(theta)}. I even
briefly entertained the idea of inheriting from std::complex to get my
Point class.
But is it a class? It doesn''t seem to have any other invariant than "it has
two components". But that /is/ an invariant that is determined when the
object is created. But that is true of any struct with two members.
So what''s the advantage of protecting the components of Point? One argument
people give is that it prevents me from inadvertently modifying the data.
That seems a bit spurious to me in this case. Another, more reasonable
argument that Stroustrup doesn''t mention is the notion of event
notification. If I change a value on Point, I may want to notify the
graphics rendering software of the change so it can schedule an update. If
I call a method to make the change, I can have the event fired as a side
effect.
So I make the components protected. So what? What dose that cost me? The
Point that I inherit in Rectangle acts just the way I want it. It inherits
everything from point that I need it to. OTOH, when I try to modify the
components of the lower right corner dxdy, I find I am not permitted to
access the protected data. So, either I use the public interface to modify
the data, or make Rectangle or some standalone function a friend of Point.
The former is a cyclic reference, and bad design, as a general rule. The
latter is something I find to be in bad taste.
If my public interface to point is well designed, writing that bit of extra
code within Rectangle is no big deal. There is one last factor I would
consider, and I honestly don''t know what the answer is. Does a decent
compiler (g++, in my case) optimize away the function calls such as:
Point<T>& operator+=(const Point& p)
{
this->x += p.x;
this->y += p.y;
return *this;
}
?
--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
推荐答案
经过26年多的处理矩形和封闭多边形。你最多
肯定希望它成为一个班级。一个建议。虽然一个带有
点的矩形，宽度和高度适合在某些点上绘制，但它会将
转换为多边形，以便ll数字可以被视为同样。
我建议你处理矩形作为2点，任何2
对角。选择2，并做那样的事情。在这里，它总是
左下角和右上角。 Id drawinf图片到屏幕
是m =你的主要目标然后一定只保留一个点，w和h。
按类vs结构。结构将由你没有什么是你的写作
类的方法来处理矩形。
class rect {
private ：
int llx，lly，urx，ury;
public：
rect（）{llx = lly = MAX_INT32; urx = ury = MAX_INT32; };
移动
旋转
镜子
翻转
copy
...
};
在过去的15年里，我用c和结构模拟了c ++对象。
typedef struct
{
int llx，lly，urx，ury;
} rect_t;
typedef rect_p * rect_t ;
rect_move（rect_p，int x，int y）
这里我使用了一个类对象的结构会有同样的麻烦
知道结构存在的位置或已经启动的结果。
我相信如果我开始使用
，这一切都会更容易阅读c ++类。
Steven T. Hatton写道：
After 26+ years of dealing with rectangles and closed polygons. you most
surely want it to be a class. One suggestion. While a rectangle with a
point, width and height work well for drawing at some point it will have
to be converted to a polygon so that ll figures may be treated the same.
I would suggest that you deal with rectangles as 2 points, any 2
opposite corners. Pick 2 and do everything that way. Here, it''s always
been the lower left and upper right. Id drawinf picture to the screen
are m=you main objective then by all means keep only a point,w and h.
As per class vs struct. Struct will by you nothing is your writing
methods of a class to deal with the rect.
class rect{
private:
int llx,lly,urx,ury;
public:
rect() { llx = lly = MAX_INT32; urx = ury = MAX_INT32; };
move
rotate
mirror
flip
copy
...
};
Over the past 15 years I have simulated c++ objects with c and structures.
typedef struct
{
int llx,lly,urx,ury;
} rect_t;
typedef rect_p *rect_t;
rect_move(rect_p,int x,int y)
Here I used a struct whan a class object would have same me the trouble
of knowing where a structure existed or has it been initailized.
I believe all this would have been much easire and easire to read if I
had started with c++ classes.
Steven T. Hatton wrote:
以下可能会让你们很多人感到愚蠢，但它代表了我发现的那种del我自己在尝试做出设计决定时。这是一个为了学习使用C ++而编写的玩具项目。因此，对于我来说，给出
情况下面提到的考虑金额是有道理的。说实话，
我很惊讶有关这种看似简单的情况的说法很多。
我正在努力学习使用C ++ Stroustrup在TC ++（PL）中告诉我们的方式。
他有一些不同的指导方针来确定是否应该将某些东西视为一个类或一个结构（在''C'意义上）。一个衡量标准是它是否具有需要保留的不变量。所以，假设我有一个矩形
{x，y，w，h}其中x和y是左上角的坐标，w
和h分别是宽度和高度。我可以任意改变那个集合中的任何元素并且仍然有一个矩形（假设w> 0，h> 0，或者我给备选方案赋予意义）。他的另一个标准是，是否有两种可能的同一抽象表示。如果是这样，它会认为应该是一个类我要说是的。
struct Rectangle {size_t x，y，w，h;};
struct Point { size_t x，y;};
struct RectanglePts {Point xy，dxdy;}
我可能还想要一些方便的功能，例如
Rectangle& Rectangle :: widen（const size_t dw）{this-> w + = dw;归还这个; }
矩形& Rectangle :: move（const Point dxy）{
this-> x + = dxy.x;
this-> y + = dxy.y;
返回此; }
有趣的是，有一个操作可以识别不变量。 Rectangle :: xy和Rectangle :: dxdy
之间的位移应保留在翻译下。同样，缩放操作应该保持两边长度之间的比例。
然后我问Rectangle是否应该从Point派生。无论选择哪个都有争论。他建议提出这样一个问题：这个对象有两个你正在考虑作为基类的东西吗？。起初我可能会说
是，我可以有两点以上。我只需要两个点来定义矩形。这就是说矩形应该有Point成员，而不是Point。但是，如果我们说一点不仅仅是一个点，那么它就是一个位置。所以我们再问一遍，它可以有两个吗？。嗯，是的，不是。
它可以有很多位置。在数学上，矩形中有无数个点。但是矩形作为一个整体只能实际上有一个位置。
将矩形视为具有大小和形状的位置是有道理的。我们可能会将它视为一个几何对象，而不是将Point视为一对坐标或一个
位置。它可以被视为基本的几何对象。如果没有位置，我们绝不会在屏幕上绘制
几何对象。我可以使用
同一组操作来移动任何几何对象，就像我用来移动一个点。我甚至可以编写一些操作符来添加两个点作为向量，然后
在其他几何对象中继承它们。如果我将一个Point添加到
矩形，则相当于移动rectangel，使得左上角的
坐标具有添加点的组件
。
我还没有完全确定的测试来确定一个矩形
应该是一个类还是一个结构。我也无法明确决定它是否应该是一个点并且有另一个点，或者它应该有两个点。由于涉及定位的原因，我赞成
前者。
但是现在，我必须考虑一点。它可以有两个表示吗？
愚蠢的{x，y} odered对？对！ {r cos（theta），r sin（theta）}。我甚至简单地接受了从std :: complex继承我的
Point类的想法。
但它是一个类吗？它似乎没有任何其他不变量而不是它有两个组件。但是/是/在创建
对象时确定的不变量。但是对于任何具有两个成员的结构都是如此。
那么保护Point组件的优势是什么？人们给出的一个论点是它可以防止我无意中修改数据。
在这种情况下，这似乎有点虚假。 Stroustrup没有提到的另一个更合理的论点是事件
通知的概念。如果我在Point上更改了值，我可能想要通知
图形渲染软件更改，以便它可以安排更新。如果我调用一个方法进行更改，我可以将事件作为一个副作用触发。
所以我保护组件。所以呢？我花了多少剂量？我在Rectangle中继承的点就像我想要的那样。它从我需要的地方继承了所有东西。 OTOH，当我尝试修改右下角dxdy的组件时，我发现我不允许访问受保护的数据。所以，要么我使用公共接口来修改数据，要么使Rectangle或某些独立函数成为Point的朋友。
前者是循环引用，而且设计不好，作为一般规则。
后来我的公共界面设计得很好，在Rectangle中编写那些额外的代码并不是什么大不了的事。 。我会考虑最后一个因素，老实说，我不知道答案是什么。一个体面的编译器（在我的例子中是g ++）优化了函数调用，例如：
Point< T>& operator + =（const Point& p）
{
this-> x + = px;
this-> y + = py;
return * this;
}
？
The following may strike many of you as just plain silly, but it represents
the kind of delelima I find myself in when trying to make a design
decision. This really is a toy project written for the purpose of learning
to work with C++. It therefore makes some sense for me to give the
situation the amount of consideration presented below. To be quite honest,
I''m amazed at the amount there is to say about such a seemingly simple
situation.
I''m trying to learn to use C++ the way Stroustrup tells us to in TC++(PL).
He has a few different guidelines for determining if something should be
treated as a class or a struct (in the ''C'' sense). One measure is whether
it has an invariant that needs to be preserved. So, say I have a rectangle
{x,y,w,h} where x and y are the coordinates of the top left corner, and w
and h are width and height respectively. I can arbitrarily change any
element of that set and still have a rectangle (assuming w > 0, h > 0, or I
assign meaning to the alternatives). Another criteria he has is whether
there are two possible representations of the same abstraction. If so, it
argues that it should be a class To that I say yes.
struct Rectangle{size_t x, y, w, h;};
struct Point{size_t x,y;};
struct RectanglePts{Point xy, dxdy;}
I may also want some convenience functions such as
Rectangle& Rectangle::widen(const size_t dw){ this->w += dw; return this; }
Rectangle& Rectangle::move(const Point dxy){
this->x += dxy.x;
this->y += dxy.y;
return this; }
Interestingly, there is an operation for which when an invariant can be
identified. The displacement between Rectangle::xy and Rectangle::dxdy
should be preserved under translations. Likewise scale operations should
preserve the ratio between the lengths of the sides.
Then I ask if Rectangle should derive from Point. There are arguments for
either choice. He suggests asking the question "can the object have two of
the things you are considering as a base class". At first I might say
"yes", I can have more than two points. I only need two points to define
the rectangle. That argues that the Rectangle should have Point members,
rather than be a Point. But what if we say a point isn''t just a point,
it''s a location. So we ask again, "can it have two?". Well, yes and no.
It can have many locations within it. Mathematically, there are an
infinite number of points in a rectangle. But the rectangle as a whole
only realistically has one position.
And it makes some sense to treat the rectangle as a position with a size and
shape. Rather than thinking of a Point as a pair of coordinates, or a
location, we might think of it as a geometric object. It could be
considered as the fundamental geometric object. We will never draw a
geometric object on a screen without it having a location. I can use the
same set of operations to move any geometric object, as I use to move a
point. I might even write some operators to add two points as vectors, and
then inherit these in other geometric objects. If I add a Point to a
rectangle it is equivalent to moving the rectangel such that the
coordinates of the top left corner have the components of the point added
to them.
I have not completely definitive test to determine whether a rectangle
should be a class or a struct. Nor can I clearly decide if it should be a
Point and have another Point, or if it should have two points. I favor the
former for the reasons involving positioning.
But now, I have to consider a point. Can it have two representations? A
stupid {x,y} odered pair? Yup! {r cos(theta), r sin(theta)}. I even
briefly entertained the idea of inheriting from std::complex to get my
Point class.
But is it a class? It doesn''t seem to have any other invariant than "it has
two components". But that /is/ an invariant that is determined when the
object is created. But that is true of any struct with two members.
So what''s the advantage of protecting the components of Point? One argument
people give is that it prevents me from inadvertently modifying the data.
That seems a bit spurious to me in this case. Another, more reasonable
argument that Stroustrup doesn''t mention is the notion of event
notification. If I change a value on Point, I may want to notify the
graphics rendering software of the change so it can schedule an update. If
I call a method to make the change, I can have the event fired as a side
effect.
So I make the components protected. So what? What dose that cost me? The
Point that I inherit in Rectangle acts just the way I want it. It inherits
everything from point that I need it to. OTOH, when I try to modify the
components of the lower right corner dxdy, I find I am not permitted to
access the protected data. So, either I use the public interface to modify
the data, or make Rectangle or some standalone function a friend of Point.
The former is a cyclic reference, and bad design, as a general rule. The
latter is something I find to be in bad taste.
If my public interface to point is well designed, writing that bit of extra
code within Rectangle is no big deal. There is one last factor I would
consider, and I honestly don''t know what the answer is. Does a decent
compiler (g++, in my case) optimize away the function calls such as:
Point<T>& operator+=(const Point& p)
{
this->x += p.x;
this->y += p.y;
return *this;
}
?
-
___ _ ____ ___ __ __
/ _）（_）/ / _ __ / _ \ ___ _ / / _ / / ____ ___
/ _ / / / / // / / ___ / _` / __ / __ / _ \ / _ \
/ ____ / _ / _ / _ / \ _，/ / _ / \\ _ _，_ / \ __ / \ __ / \ ___ / _ // _ /
/ ___ /
德州仪器（TI）ASIC电路设计方法集团
达拉斯，得克萨斯州，214-480-4455， b - ****** @ ti.com
Steven T. Hatton写道：
Steven T. Hatton wrote:
以下可能会让你们中的许多人感到愚蠢，但它代表了我在尝试做出设计决定时发现自己的那种delima。这是一个为了学习使用C ++而编写的玩具项目。因此，对于我来说，给出
情况下面提到的考虑金额是有道理的。说实话，
我很惊讶有关这种看似简单的情况的说法。
[snip]
然后我问Rectangle是否应该从Point派生。无论选择哪个都有争论。他建议提出这样一个问题：这个对象有两个你正在考虑作为基类的东西吗？。起初我可能会说
是，我可以有两点以上。我只需要两个点来定义矩形。这就是说矩形应该有Point成员，而不是Point。但是，如果我们说一点不仅仅是一个点，那么它就是一个位置。所以我们再问一遍，它可以有两个吗？。嗯，是的，不是。
它可以有很多位置。在数学上，矩形中有无数个点。但矩形作为一个整体
只是实际上有一个位置。
The following may strike many of you as just plain silly, but it represents
the kind of delelima I find myself in when trying to make a design
decision. This really is a toy project written for the purpose of learning
to work with C++. It therefore makes some sense for me to give the
situation the amount of consideration presented below. To be quite honest,
I''m amazed at the amount there is to say about such a seemingly simple
situation. [snip]
Then I ask if Rectangle should derive from Point. There are arguments for
either choice. He suggests asking the question "can the object have two of
the things you are considering as a base class". At first I might say
"yes", I can have more than two points. I only need two points to define
the rectangle. That argues that the Rectangle should have Point members,
rather than be a Point. But what if we say a point isn''t just a point,
it''s a location. So we ask again, "can it have two?". Well, yes and no.
It can have many locations within it. Mathematically, there are an
infinite number of points in a rectangle. But the rectangle as a whole
only realistically has one position.
[snip]
你问的不仅仅是什么东西应该是
级别。你问的是继承，成员访问，
和封装。
通过封装，矩形不是一个点。矩形
可能包含点，线段或顶点。由于存在
变化，因此问题变为有人需要什么？b $ b来了解矩形才能使用它？这是
公共界面发挥作用的地方。
我们知道矩形有高度，宽度和面积
（从高度和宽度得出）。我们知道
" top"和底部线必须是平行的，所以必须是
边线。这是基本的矩形。
矩形可能有一个位置。可以说具有位置的
矩形是一个新对象。为了简单起见，让它成为那样（在这个讨论中）。
那么，如何描述这个位置呢？最简单的
方法是选择一个角作为锚，然后应用
高度的方向和宽度与方向。
这个说一个Rectangle_With_Location _is_a_矩形
：锚点位置，
a高度方向，
和宽度方向。 />
到目前为止，我还没有说明一个位置是什么。到目前为止
封装并没有建议需要知道
使用Rectangle_With_Location。
为了实现这个抽象的愿景，我们应该给用户提供他们需要知道的信息。我们
可以将该位置实现为笛卡尔点。我们
可以使用极坐标
或其他系统来实现该位置。如果我们让客户访问数据成员
，那么我们就无法使我们的
Rectangle_With_Location适应不同的构造
的位置。我们不希望提供一个界面
来指定位置结构的细节;
限制了我们课程的使用。
class Rectangle
{
public：
距离get_width（void）const;
距离get_height（void）const;
private：
距离高度;
距离宽度;
};
类Rectangle_With_Location
：public Rectangle
{
public：
Rectangle_With_Location（const Location& anchor，
const Direction& height_direction，
const距离&高度，
const方向& width_direction，
const距离&宽度）;
};
所以，基本主题是保持抽象，直到
他们达到需要细节的水平。通常，
涉及一些平台细节。
-
Thomas Matthews
C ++新闻组欢迎信息：
http：// www。 slack.net/~shiva/welcome.txt
C ++常见问题： http://www.parashift.com/c++-faq-lite
C常见问题： http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c ++ faq：
http://www.comeaucomputing.com/learn/faq/
其他网站：
http://www.josuttis.com - C ++ STL图书馆书籍
[snip]
You are asking more than just whether something should be a
class or not. You are asking about inheritance, member access,
and encapsulation.
By means of encapsulation, a rectangle is not a point. A rectangle
may consist of points, line segments, or vertices. Since there are
variations, the question then becomes, "What does somebody need
to know about a rectangle in order to use it?" This is where
the public interface comes into play.
We know that a rectangle has a height and a width and an area
(which is derived from height and width). We know that the
"top" and "bottom" lines must be parallel and so must the
side lines. This is the basic rectangle.
A rectangle may have a location. One could say that the
rectangle with a position is a new object. For sake of
simplicity, let it be that way (in this discussion).
So, how does one describe the location? The simplest
method is to pick a corner as an anchor then apply the
height with a direction and the width with a direction.
This says that a Rectangle_With_Location _is_a_ Rectangle
with: an anchor position,
a direction for the height,
and a direction for the width.
So far, I haven''t specified what a location is. So far
encapsulation hasn''t suggested a need to know in order
to use Rectangle_With_Location.
In order to achieve this abstract vision, we should give
the user''s only the information they need to know. We
may implement the location as a Cartesian point. We
could implement the location using Polar coordinates
or some other system. If we give the clients access to
the data members, then we lose the ability to adapt our
Rectangle_With_Location to different constructs for
the location. We would _not_ want to provide an interface
that specifies the details of the location structure; for
that limits the usage of our class.
class Rectangle
{
public:
Distance get_width(void) const;
Distance get_height(void) const;
private:
Distance height;
Distance width;
};
class Rectangle_With_Location
: public Rectangle
{
public:
Rectangle_With_Location(const Location& anchor,
const Direction& height_direction,
const Distance& height,
const Direction& width_direction,
const Distance& width);
};
So, the basic theme is to keep things abstract until
they hit a level where specifics are required. Usually,
that involves some platform specifics.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
Thomas Matthews写道：
Thomas Matthews wrote:
涉及一些平台细节。
嗯。这就是几年前我接近这样的问题的方式。我相信这是一个非常好的方法，应该已经采取了它。我想部分
之所以我不是因为我已经知道
演示环境会是什么样子。我实际上正在向后工作
，从而更抽象。在我发布原始消息之后，我花了很多钱来看看Trolltech是如何做到这一点的。有趣的是，他们采取了一种方法
我没有提到。四个不同的值而不是两个点。当然
他们提供界面，以便它可以显示为四个点等。
我觉得它们存储实际坐标有点有趣
反对头寸和抵消。我从'xterm -geometry 80x120 + 400 + 600''得到位置和偏移的想法
。他们为Mac
做的宏观修改也有点有趣。这是他们的QRect标题。我相信整个定义和声明都是b
。一切似乎都是内联的。
http://doc.trolltech.com/3.3/qrect-h.html
-
STH
哈顿定律：只有一个不可侵犯的法律
KDevelop： http://www.kdevelop.org SuSE： http：// www.suse.com
Mozilla： http：// www .mozilla.org
Hmmm. That''s the way I approached problems like this a few years back. I
believe it is a very good approach, and should have taken it. I guess part
of the reason I didn''t is because I already have an idea of what the
presentation environment will look like. I''m actually working backwards
from there, to the more abstract. After I posted the original message I
took a look at how Trolltech does it. Interestingly, they took an approach
I didn''t mention. Four distinct values rather than two points. Of course
they present the interface so that it can appear as four points, etc.
I find it a bit interesting that they store the actual coordinates as
opposed to a position and offset. I get the idea of position and offset
from `xterm -geometry 80x120+400+600''. The macro mangling they do for Mac
is also a bit interesting. Here''s their header for QRect. I believe it is
the entire definition as well as declaration. Everything seems to be
inlined.
http://doc.trolltech.com/3.3/qrect-h.html
--
STH
Hatton''s Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
这篇关于Rectangle：struct还是class？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
