构造函数的参数数量

ali*_*hoo 35 c++ parameters refactoring constructor design-patterns

我有一个类,需要将12个参数传递给它的构造函数.所以我认为这个类的设计有问题.

我想询问是否有任何关于类设计的设计模式或一般规则集合,特别是它的构造函数.

Pét*_*rök 37

12个参数对我来说肯定听起来太多了.减少数量的选项有:

  1. 通过将逻辑相关参数分组到对象中并传递该对象而不是单个参数来引入参数对象.

  2. 介绍一个Builder(可选择使用方法链接).这不会减少实际参数列表,但它会使代码更具可读性,并且如果您有多个具有不同参数的不同创建方案,则特别有用.而不是

    MyClass someObject = new MyClass(aFoo, aBar, aBlah, aBaz, aBorp, aFlirp, 
            andAGoo);
    MyClass anotherObject = new MyClass(aFoo, null, null, aBaz, null, null, 
            andAGoo);
    
    Run Code Online (Sandbox Code Playgroud)

    你可以有

    MyClass someObject = new MyClassBuilder().withFoo(aFoo).withBar(aBar)
            .withBlah(aBlah).withBaz(aBaz).withBorp(aBorp).withFlirp(aFlirp)
            .withGoo(aGoo).build();
    MyClass anotherObject = new MyClassBuilder().withFoo(aFoo).withBaz(aBaz)
            .withGoo(aGoo).build();
    
    Run Code Online (Sandbox Code Playgroud)
  3. (也许我应该从这开始;-)分析参数 - 在构造函数中是否真的需要它们(即强制性的)?如果参数是可选的,您可以通过常规setter而不是构造函数来设置它.

  • 在我尝试1.或2.之前,我肯定会做3. (5认同)
  • +1为构建器方法,它是一个优雅的解决方案 (3认同)

Ste*_*and 9

如果你的函数需要11个参数,你可能已经忘了一个

我喜欢这句话,因为它总结了一切:糟糕的设计需要糟糕的设计.

我从" C++编码标准:101规则,指南和最佳实践"一书中摘录了Herb Sutter,Andrei Alexandrescu.

编辑:直接引用是如果您有一个包含十个参数的过程,您可能错过了一些.它本身就是Alan Perlis的一句话.

具有如此多参数的函数是不良设计的symtom.其中一种可能性是尝试将这些参数的一部分封装在具有已定义目标的实体/类中.(不是列出没有有意义结构的所有参数的垃圾类).


永远不要忘记单一责任原则 因此,类的大小仍然有限,因此成员参数的数量有限,因此其构造函数所需参数的大小受到限制.就像下面的评论之一所说,具有如此多构造函数参数的类可能会处理太多无用的细节,而与其主要目标无关.


建议看一下这个:有多少参数太多了?

  • +1这是一种代码气味.听起来这个班级正在处理很多细节.但我认为参数类实际上只是掩盖了气味. (2认同)

dar*_*rak 6

12参数,设计很可能是错误的.

参数做了什么?

  • 该类是否只是将它们发送到其他构造函数中?那么也许它应该只接受准备构造对象的接口.
  • 该类是否很大并且使用所有这些参数做了很多事情?然后课程要承担很多责任,并且应该接受负责细节的课程.
  • 参数中是否有"簇"?也许是创作中一类的一些参数.封装它们并给予它们适当的责任.

另一种选择是,这是低水平,性能关键结构的参数,在这种情况下,设计只需要回位,但这种情况很少发生.