构造函数应该有多少个变量？

Question

我意识到这是一个非常开放的问题,可以得到各种各样的答案,但是这里有.

使用C#(或Java,或任何OO语言),是否有一个通用规则说明应该将多少变量传递给构造函数？我传递给扩展类的构造函数的变量数似乎失控了.

为了封装类的数据,我将成员声明为private,在构造函数中初始化它们,并使用公共访问器.

这是一个例子:

public class A
{
  private int var1;
  private int var2;
  private int var3;

  //3 variables passed in
  public A(int v1, int v2, int v3)
  {
    var1 = v1;
    var2 = v2;
    var3 = v3;
  }

  //Properties (accessors) here
}

public class B : A
{
  private int var4;
  private int var5;

  //5 variables passed in
  public B(int v1, int v2, int v3, int v4, int v5)
  : base(v1,v2,v3)
  {
    var4 = v4;
    var5 = v5;
  }

  //Properties (accessors) here
}

public class C : B
{
  private int var6;
  private int var7;

  //7 variables passed in !!!
  public C(int v1, int v2, int v3, int v4, int v5, int v6, int v7)
  : base(v1,v2,v3,v4,v5)
  {
    var6 = v6;
    var7 = v7;
  }

  //Properties (accessors) here
}

我的构造函数通常传递不同的对象,而不仅仅是int.当我开始将7个变量传递给子类的构造函数时,我开始质疑我的设计,但是我也很难找到一种不同的方法来实现这一点.

这被认为是糟糕的编程习惯吗？您应该传递给构造函数的变量数量是否有一般限制？

Answer 1

对我来说,正确答案是:

您应该传入尽可能多的变量,以便在非无效状态下设置对象.

其他任何"选项",我更喜欢作为属性,特别是现在C#提供对象初始化器.

Answer 2

一般来说,我发现如果超过3个,那就是对设计进行快速健全性检查的标志.如果超过5,这是一个重大的警告,设计可能有问题.

但是,请注意"可能"这个词 - 最后,唯一真正的规则是使用尽可能多的功能,不多也不少.总有例外情况和更多参数最有意义的情况.

如果参数以某种方式相关,则应将它们封装到容器类中.

如果参数不相关 - 例如将它们分组到容器类中是没有意义的 - 您的类可能做了太多事情.通常没有理由让一个班级知道7个完全不同的信息.将你的班级分成几个班级.将参数3和4委托给子类以及将5,6和7委托给另一个类可能是有意义的 - 而您的父类只是协调它们之间的操作.

Answer 3

很难将一个坚硬,快速的数字放到"太多"的数字上.真正的问题是:你的班级在做什么？班级做得太多了吗？如果是这样,是时候将课程分成更小,更简洁的课程.

构造函数参数应包括定义类的依赖项/输入所需的数量.如果将类减少为生命中有一个作业,那么构造函数参数可能是正确的.