【问题标题】:Dealing with multiple input parameters using wrapper class使用包装类处理多个输入参数
【发布时间】: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


【解决方案1】:

最大的好处是:

  • 绝缘变化。你可以加 参数类的新属性 并且不必改变类 使用它或它的任何调用者。

  • 链接时的代码缩减 方法。如果MyClass需要通过 它的参数,MyInputClass 省去了一堆代码。

【讨论】:

    【解决方案2】:

    这里有一些原因,想用一个参数类:

    • 可重用性:您可以将参数保存在变量中并重用它们,也许可以用其他方法。
    • 关注点分离:在参数类中执行参数处理,比如验证哪些参数是活动的,哪些参数在正确的范围内等;你的计算方法只知道怎么计算,以后就知道各在哪里了,不混逻辑。
    • 您可以在计算器方法中添加新值并将影响降至最低。
    • 也许您的计算器方法可以应用于两组不同的参数,例如整数和双精度。只需编写一次计算逻辑并更改参数对象,更具可读性/可维护性/更快。

    有些类不需要在构造函数中初始化每个字段。有时二传手是要走的路。

    【讨论】:

      【解决方案3】:

      所有其他点都是完全有效和合理的。以下是一些权威文本的一点强化:

      Code Complete 建议您将任何例程的参数数量限制为七个,因为“七是人们理解的神奇数字”。然后它继续建议传递超过七个参数会增加与调用范围的耦合,并且您应该改用结构化变量(ala MyInputClass)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2022-11-10
        • 1970-01-01
        • 2012-09-25
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多