【发布时间】:2010-11-10 03:11:05
【问题描述】:
作为this 的延续,我有以下新手问题:
构建一个需要大量输入参数的包装类和将这些参数直接输入到最终构造函数有什么区别?
不要误会我的意思,我认为多输入参数的东西非常丑陋,我正试图绕过它,因为就像那个问题的海报一样,我需要处理一个类似计算器的类需要很多参数。但是我不明白输入参数的包装类会解决什么问题,因为我还需要构建输入类——这和其他选择一样难看。
总而言之,我不这么认为:
MyClass::MyClass(int param1, int param2, int param3... int paramN)
{
this->param1 = param1;
this->param2 = param2;
this->param3 = param3;
...
this->paramN = paramN;
}
...与此大不相同:
Result MyClass::myInterface(MyInputClass input)
{
//perform calculations
}
MyInputClass::MyInputClass(int param1, int param2, int param3... int paramN)
{
this->param1 = param1;
this->param2 = param2;
this->param3 = param3;
...
this->paramN = paramN;
}
当然,我会尽量避免使用二传手。
我在这里遗漏了什么吗?我很想对此有所了解,因为我还是一个新手程序员。
【问题讨论】:
-
作为旁注,您为什么要在参数类中避免设置器?
-
因为我不太喜欢二传手的想法。一直争论不休,但我真的认为 setter 完全违背了为对象提供干净接口、按公共和私有字段分隔数据的想法。这并不意味着它们不应该被使用。这只是意味着我认为应该谨慎使用它们,并且只有在没有太多选择的情况下。
-
如果参数只在构造函数中传递,并且以后没有从另一个对象对它们进行更改,那么避免设置器是非常好的,也是一个非常好的选择
标签: api oop interface constructor