构造函数的参数数量
我有一个类需要将 12 个参数传递给其构造函数。所以我觉得这个类的设计有问题。
我想问是否有关于类（尤其是其构造函数）设计的设计模式或通用规则集合。
I have a class that needs 12 parameters to be passed to its constructor. So I think that there is something wrong with the design of this class.
I would like to ask if there is any design pattern or a general collection of rules regarding the design of a class, especially its constructor.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
12 个参数对我来说确实太多了。减少其数量的选项有：
通过对逻辑相关的参数进行分组来引入参数对象到一个对象中并传递该对象而不是单个参数。
引入一个Builder（可选地使用方法链接）。这不会减少实际的参数列表，但会使代码更具可读性，如果您有多个具有不同参数的不同创建场景，则特别有用。所以而不是
你可以拥有
（也许我应该从这个开始；-）分析参数 - 构造函数中是否真的需要所有这些参数（即强制）？如果参数是可选的，您可以通过其常规设置器而不是构造函数来设置它。
12 parameters definitely sound too many to me. Options to reduce their numbers are:
Introduce Parameter Object by grouping logically related parameters into an object and passing that object instead of the individual parameters.
Introduce a Builder (optionally with method chaining). This does not reduce the actual parameter list but it makes the code more readable, and is especially useful if you have several different creation scenarios with varying parameters. So instead of
you can have
(Maybe I should have started with this ;-) Analyse the parameters - Are all of them really needed in the constructor (i.e. mandatory)? If a parameter is optional, you may set it via its regular setter instead of the constructor.
如果你的函数需要十一个参数，你可能又忘记了一个。
我喜欢这句话，因为它总结了一切：糟糕的设计需要糟糕的设计。
我摘自 Herb Sutter、Andrei Alexandrescu 所著的《C++ 编码标准：101 条规则、指南和最佳实践》一书。
编辑：直接引用是如果您有一个包含十个参数的过程，您可能会错过一些。它本身就是来自 Alan Perlis 的引述。
具有如此多参数的函数是糟糕设计的症状。
一种可能性是尝试将这些参数的一部分封装在具有已定义目标的实体/类中。 （不是列出没有有意义结构的所有参数的垃圾类）。
永远不要忘记单一责任原则
因此，类的大小仍然受到限制，成员参数的数量也受到限制，因此其构造函数所需的参数的大小也受到限制。正如下面的评论之一所说，具有如此多构造函数参数的类可能会处理太多无用的细节，而与其主要目标无关。
也建议看一下这个：有多少参数太多？
If your function takes eleven parameters, you probably have forgotten one more
I love this sentence because it sums it all: Bad design calls for bad design.
I took this is from the book C++ Coding Standards: 101 Rules, Guidelines, And Best Practices by Herb Sutter, Andrei Alexandrescu.
Edit: The direct quote is If you have a procedure with ten parameters, you probably missed some. It is itself a quote from Alan Perlis.
Functions with so many parameters are a symtom of bad design.
One of the possibility is to try to encapsulate part of these parameters in an entity/class that has a defined goal. (not a garbage class that would list all parameters without meaningful structure).
Never forget the Single Responsibility Principle
As a consequence, classes remain limited in size, and as a consequence, limited in number of member paramters, and thus limited in the size of parameters needed for its constructors. Like one of the comments below says, the class with so much constructor parameters may handle too much futile details independent of its main goal.
A look at this one is advised too: How many parameters are too many?
12个参数，很可能是设计有问题。
参数是做什么的？
另一种选择是，这是低级、性能关键结构的参数，在这种情况下，设计只需退居二线，但这种情况很少见。
12 Parameters, something is most probably wrong with the design.
What is done with the parameters?
The alternative is that this is parameters for a lowlevel, performance critical construction, in which case the design just have to take back seat, but that is rarely the case.
如果可能的话，您可以按类对参数进行分组，并将它们的实例传递给构造函数。
if it is possible you may group the parameters by classes and pass their instances to the constructor.
例如，我认为在使用状态模式时这是可以接受的。但是，我是否可以建议传递这些参数来自的对象（如果合适）？然后在构造函数中从中加载数据？
I think this can be acceptable when using the State pattern for example. However, might I suggest passing the object (if appropriate) that those parameters come from instead? And then in the constructor loading the data from it?