accessor / mutator - 设计'flaw' [英] accessor/mutator - design 'flaw'
问题描述
我希望我的帖子不会落入''难以说'的类别，
但是我被告知有多种用途的accessor / mutator
（获取/设置）成员函数可被视为设计缺陷。在那个
中，我正在尝试创建一个'示例''类，这是一个替代
的accessor / mutator方法。为了进一步描述问题
考虑BAR（下面）类，其中有一个成员数据in_use，FOO
需要可见性。类似的FOO有成员数据''idx''BAR
需要可见性。
就可见性而言，我可以设想三种方法。
1.公开数据成员
2.宣布BAR为FOO的朋友，反之亦然
3.使用获取/设置。这可能是一个设计上的缺陷。
如果记忆很好，项目1也暗示了''设计缺陷''所以我是
留下2，但我经常对朋友持怀疑态度。
任何指针/帮助都是适用的。
谢谢
#include< iostream>
#include" foo.h"
class BAR
{
public：
BAR（）：in_use（0）
{
// std :: cout<< " bar'的构造函数" << std :: endl;
}
~BAR（）{}
void GetPosFbkFoo（）
{
in_use ^ = 1;
if（in_use）
{
int jdx = foo.GetFbk（）;
std :: cout<< jdx<< std :: endl;
}
else //做其他事情
{
foo.ComputeTorquerCmd（） ;
}
}
私人：
int in_use;
//更多会员数据
FOO foo;
};
int main（）
{
BAR * ptrBar =新BAR;
for（int idx（0）; idx< 10; ++ idx）
ptrBar- > GetPosFbkFoo（）;
删除ptrBar;
返回0;
}
＃包括foo.h
#include< iostream>
FOO :: FOO（）：idx（0）
{
// std :: cout<< " foo的构造函数叫做 << std :: endl;
}
FOO ::〜FOO（）
{
std :: cout<< " foo destructing << std :: endl;
}
int FOO :: GetFbk（）
{
return ++ idx; //用于演示目的
}
void FOO :: ComputeTorquerCmd（）
{
//需要在这里查看in_use标志。
//方法：
// 1.公开in_use标志;
// 2.宣布BAR为FOO的朋友
// 3.使用获取/设置
}
#ifndef FOO_H
#define FOO_H
等级FOO
{
公开：
FOO（）;
~FOO（）;
int GetFbk（）;
void ComputeTorquerCmd（）;
private：
int idx;
//更多.. BAR
};
#endif
[垃圾邮件预防：用mpowell替换ma740988给我发电子邮件..]
" ma740988" <毫安****** @ pegasus.cc.ucf.edu>在消息中写道
新闻：a5 ************************* @ posting.google.co m ... < blockquote class =post_quotes>我希望我的帖子不会落入难以说出的类别，但是我被告知有多种用途的accessor / mutator
（获取/设置）成员函数可以被视为设计缺陷。在那个
中，我正在尝试创建一个示例类，这是访问器/增变器方法的另一种选择。为了进一步描述问题，请考虑具有成员数据in_use的BAR类（下面），其中FOO
需要可见性。类似的FOO有成员数据''idx''BAR需要可见。
在可见性方面我可以设想三种方法。
1.使数据成员公开
2宣布BAR是FOO的朋友，反之亦然
3.使用获取/设置。这大概指向一个设计缺陷。
如果记忆对我很好，第1项也暗示了''设计缺陷''所以我要留下2但我已经经常对''朋友'持怀疑态度'
任何指针/帮助都会有所帮助。
谢谢
＃include< iostream>
＃包括foo.h
课程BAR
{
公开：
BAR（）：in_use（0）
{
/ / std :: cout<< " bar'的构造函数" << std :: endl;
}
~BAR（）{}
void GetPosFbkFoo（）
{
in_use ^ = 1;
if（in_use）
{zh / // int jdx = foo.GetFbk（）;
std :: cout<< jdx<< std :: endl;
}
其他//做其他事情
{
foo.ComputeTorquerCmd（）;
}
}
私人：
int in_use;
//更多会员数据
FOO foo;
};
int main（）
{
BAR * ptrBar =新BAR;
for（int idx（0）; idx< 10; ++ idx）
ptrBar-> GetPosFbkFoo（）;
删除ptrBar;
返回0;
}
#include" foo.h"
#include< iostream>
FOO :: FOO（ ）：idx（0）
{st / :: // std :: cout<< " foo的构造函数叫做 << std :: endl;
}
FOO ::〜FOO（）
{
std :: cout<< " foo destructing << std :: endl;
}
int FOO :: GetFbk（）
{
return ++ idx; //用于演示目的
void FOO :: ComputeTorquerCmd（）
//
//需要在此处查看in_use标志。
//方法：
// 1.公开in_use标志;
// 2.宣布BAR为FOO的朋友
// 3.使用Get / Set
}
#ifndef FOO_H
#define FOO_H
类FOO
{
公开：
FOO（）;
~FOO （）;
int GetFbk（）;
void ComputeTorquerCmd（）;
私有：
int idx;
//更多.. BAR
};
#endif
[垃圾邮件预防：用mpowell替换ma740988给我发电子邮件..]
使用设置/获取成员不一定是设计缺陷或可怜的标志
编码，
如果设置对象的属性会导致其他一些副作用并且
这是在set方法中封装的，那么这通常是好的。在
GUI编程
世界中，小部件通常有一定数量的getter / setter，但设置颜色
例如
不仅设置内部颜色变量，它通常会使小部件
重新粉刷成
正确的颜色。
有什么不好的，就是使用一个类作为数据存储库，有大量的b / b
解决方案/ getter，
但是客户端需要执行逻辑应该通过
来完成这个课程。
关于你的例子，它似乎与
没有任何联系。
现实世界
系统所以我发现无法帮助改进它的建议。
如果你能用简单的话说出你想要的东西做，我们可能是
能够帮助在C ++中更好地建模。
dave
" Dave Townsend" <哒******** @ comcast.net>在消息新闻中写道：< i4 ******************** @ comcast.com> ...
[...] < blockquote class =post_quotes>
使用set / get成员不一定是设计缺陷或编码不良的标志，如果对象的属性设置导致其他一些方面的效果，这是在set方法中包含的，那么一般来说是好的。在GUI编程世界中，小部件通常具有一定数量的getter / setter，但是设置颜色例如不仅会设置内部颜色变量，它通常会导致小部件重新绘制在
正确的颜色。
搞定了!!因此，我试图向我的顾问澄清他对设计漏洞的意思是什么 - 看似过度 -
访问者/变种人使用。 />
我 - 现在明白了。如果我有一个FOO类和一个BAR类。
我想要BAR中的FOO，同样是FOO中的BAR。
首选解决方案是有一个共同的''东西''类，然后有
FOO和BAR继承了普通的东西类。
什么是坏的，是用的作为一个拥有众多定居者/吸气剂的数据存储库，客户需要执行应该由班级正确完成的逻辑。
我想我知道你要去哪里了。
ma ****** @ pegasus.cc.ucf.edu （ma740988）在留言中写道：< a5 ******************* *****@posting.google.co m> ...
[snip]正如我 - 现在明白了。如果我有一个FOO类和一个BAR类。
我想要BAR中的FOO，同样也是FOO中的BAR。
首选的解决方案是拥有一个共同的''东西' '上课，然后有FOO和BAR继承了普通的东西。
是的。它被称为升级。见拉科斯。 / david
I''m hoping my post here doesn''t fall into the ''hard to say'' category,
nonetheless I''ve been advised that multiple uses of accessor/mutator
(get/set) member functions can be viewed as a ''design flaw''. In that
regard I''m trying to create an ''example'' class that''s an alternative
to the accessor/mutator approach. To further describe the problem
consider the class BAR (below) which has a member data in_use that FOO
needs visibility into. Similarily FOO has member data ''idx'' that BAR
needs visibility into.
In terms of visibility I could envision three approaches.
1. Make the data members public
2. declare BAR a friend of FOO and vise versa
3. Use Get/Set. This presumably points to a design flaw.
If memory serves me well, item 1 also suggests a ''design flaw'' so I''m
left with 2 but I''ve often been leery of ''friends''
Any pointers/help appreaciated.
Thanks
# include<iostream>
# include "foo.h"
class BAR
{
public:
BAR() : in_use(0)
{
//std::cout << " bar''s constructor " << std::endl;
}
~BAR() {}
void GetPosFbkFoo()
{
in_use ^= 1;
if (in_use)
{
int jdx = foo.GetFbk();
std::cout << jdx << std::endl;
}
else // do something else
{
foo.ComputeTorquerCmd();
}
}
private:
int in_use;
// lots more member data
FOO foo;
};
int main()
{
BAR *ptrBar = new BAR;
for (int idx(0); idx < 10; ++idx)
ptrBar->GetPosFbkFoo();
delete ptrBar;
return 0;
}
# include "foo.h"
# include <iostream>
FOO::FOO() : idx(0)
{
//std::cout << " foo''s constructor called " << std::endl;
}
FOO::~FOO()
{
std::cout << " foo destructing " << std::endl;
}
int FOO::GetFbk()
{
return ++idx; // for demo purposes
}
void FOO::ComputeTorquerCmd()
{
// need visibility into the in_use flag here.
// Approach:
// 1. Make the in_use flag public;
// 2. declare BAR a friend of FOO
// 3. Use Get/Set
}
#ifndef FOO_H
#define FOO_H
class FOO
{
public:
FOO();
~FOO();
int GetFbk();
void ComputeTorquerCmd();
private:
int idx;
// more .. BAR
};
#endif
[ Spam Prevention: Replace ma740988 with mpowell to email me .. ]
"ma740988" <ma******@pegasus.cc.ucf.edu> wrote in message
news:a5*************************@posting.google.co m...I''m hoping my post here doesn''t fall into the ''hard to say'' category,
nonetheless I''ve been advised that multiple uses of accessor/mutator
(get/set) member functions can be viewed as a ''design flaw''. In that
regard I''m trying to create an ''example'' class that''s an alternative
to the accessor/mutator approach. To further describe the problem
consider the class BAR (below) which has a member data in_use that FOO
needs visibility into. Similarily FOO has member data ''idx'' that BAR
needs visibility into.
In terms of visibility I could envision three approaches.
1. Make the data members public
2. declare BAR a friend of FOO and vise versa
3. Use Get/Set. This presumably points to a design flaw.
If memory serves me well, item 1 also suggests a ''design flaw'' so I''m
left with 2 but I''ve often been leery of ''friends''
Any pointers/help appreaciated.
Thanks
# include<iostream>
# include "foo.h"
class BAR
{
public:
BAR() : in_use(0)
{
//std::cout << " bar''s constructor " << std::endl;
}
~BAR() {}
void GetPosFbkFoo()
{
in_use ^= 1;
if (in_use)
{
int jdx = foo.GetFbk();
std::cout << jdx << std::endl;
}
else // do something else
{
foo.ComputeTorquerCmd();
}
}
private:
int in_use;
// lots more member data
FOO foo;
};
int main()
{
BAR *ptrBar = new BAR;
for (int idx(0); idx < 10; ++idx)
ptrBar->GetPosFbkFoo();
delete ptrBar;
return 0;
}
# include "foo.h"
# include <iostream>
FOO::FOO() : idx(0)
{
//std::cout << " foo''s constructor called " << std::endl;
}
FOO::~FOO()
{
std::cout << " foo destructing " << std::endl;
}
int FOO::GetFbk()
{
return ++idx; // for demo purposes
}
void FOO::ComputeTorquerCmd()
{
// need visibility into the in_use flag here.
// Approach:
// 1. Make the in_use flag public;
// 2. declare BAR a friend of FOO
// 3. Use Get/Set
}
#ifndef FOO_H
#define FOO_H
class FOO
{
public:
FOO();
~FOO();
int GetFbk();
void ComputeTorquerCmd();
private:
int idx;
// more .. BAR
};
#endif
[ Spam Prevention: Replace ma740988 with mpowell to email me .. ]
Use of set/get members is not necessarily a design flaw or the sign of poor
coding,
if the setting of a property of the object causes some other side effect and
this is encapulated in the set method, then that is generally good. In the
GUI programming
world, widgets generally have a numer of getter/setters, yet setting a color
for instance will
not only set the internal color variable, it will normally cause the widget
to be repainted in
the correct color.
What is bad, is using a class as a data depository with the multitude of
settters/getters,
yet the client needs to perform the logic which should rightfully be done by
the class.
With respect to your example, it doesn''t seem to have any connection with a
real-world
system so I find it impossible to help with a suggestion to improve it.
If you can state in simple words what you are trying to do, we might be
able to help model it better in C++.
dave
"Dave Townsend" <da********@comcast.net> wrote in message news:<i4********************@comcast.com>...
[...]
Use of set/get members is not necessarily a design flaw or the sign of poor
coding, if the setting of a property of the object causes some other side
effect and this is encapulated in the set method, then that is generally
good. In the GUI programming world, widgets generally have a numer of
getter/setters, yet setting a color for instance will not only set the
internal color variable, it will normally cause the widget to be repainted in
the correct color.
Got it!! So I tried to get clarification from my adviser on what he
meant by ''design flaw'' with regard to - seemingly excessive -
accessor/mutator usage.
As I - now understand things. If I have a class FOO and a class BAR.
I want ''something'' of FOO in BAR, likewise something of BAR in FOO.
The preferred solution is to have a common ''stuff'' class, then have
FOO and BAR inherit from the common stuff class.
What is bad, is using a class as a data depository with the multitude of
settters/getters, yet the client needs to perform the logic which should
rightfully be done by the class.
I think I see where you''re going here.
ma******@pegasus.cc.ucf.edu (ma740988) wrote in message news:<a5************************@posting.google.co m>...
[snip]As I - now understand things. If I have a class FOO and a class BAR.
I want ''something'' of FOO in BAR, likewise something of BAR in FOO.
The preferred solution is to have a common ''stuff'' class, then have
FOO and BAR inherit from the common stuff class.
Yes. It''s called escalation. See Lakos. /david
这篇关于accessor / mutator - 设计'flaw'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
