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屋!