java 方法有8个参数，大于7个授权
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/49535099/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Method has 8 parameters, which is greater than 7 authorized
提问by Baji Shaik
When I am scanning code with sonar lint the following code shows the bug as "Method has 8 parameters, which is greater than 7 authorized"
当我使用声纳 lint 扫描代码时，以下代码将错误显示为“方法有 8 个参数，授权大于 7”
@PutMapping("/something")
public List<SomeList> updateSomeThing(@PathVariable final SomeCode code,
@PathVariable final SomeId id,
@PathVariable final String testId,
@PathVariable final String itemId,
@RequestBody final List<Test> someList,
@RequestHeader("test") final String testHeader,
final HttpServletRequest request,
final SomeHeaders someHeaders)
Note: This is a controller method we can not skip any parameters
注意：这是一个控制器方法我们不能跳过任何参数
FYI: Eclipse showing a quick fix as squid:S00107
仅供参考：Eclipse 显示快速修复为鱿鱼：S00107
Anybody have any idea how to resolve this bug?
有人知道如何解决这个错误吗？
回答by Andremoniy
There are two things to consider here.
这里有两件事需要考虑。
- You can adjust this rule in Sonar and increase the number of authorized parameters. Say put it 10 instead of default (?) 7.
- 您可以在 Sonar 中调整此规则并增加授权参数的数量。假设将其设为 10 而不是默认值 (?) 7。
UPD: the advice below is based on the old question version. It might be not applicable to the new question context any more.
UPD：以下建议基于旧问题版本。它可能不再适用于新的问题上下文。
- But generally you should reconsider your method interface. Having many arguments means that something can be wrong in your architecture and the Single responsibility principlemight be broken.
- 但通常你应该重新考虑你的方法接口。有很多参数意味着您的架构中可能会出现问题，并且单一职责原则可能会被破坏。
Say in your particular example, I would expect, that you can have an aggregate class Order:
在您的特定示例中，我希望您可以拥有一个聚合类Order：
public class Order {
private CountryCode countryCode;
private String orderId;
private User user;
private String orderId;
private String item;
private List<Person> persons;
private ShippingAddress address;
private PaymentMethod payment;
private Product product;
// ...
}
Which is much logical to manage instead of dealing with many parameters. Then your issues will be solved automatically:
管理而不是处理许多参数是非常合乎逻辑的。然后您的问题将自动解决：
@GetMapping
public void updateSomething(Order order) { ... }
回答by srinivasan Y
This is an enhancement required to the default rules configured in sonar. According to sonar rules the method annotated with @RequestMapping is not bound to above rules of "Methods should not have more than 7 parameters". Please find the screenshot calling the exception.Sonar screenshot stating the exception
这是声纳中配置的默认规则所需的增强功能。根据声纳规则，使用@RequestMapping 注释的方法不受上述“方法不应有超过 7 个参数”的规则约束。请找到调用异常的屏幕截图。声纳屏幕截图说明异常
According to sonar, "Methods annotated with Spring's @RequestMapping may have a lot of parameters, encapsulation being possible. Such methods are therefore ignored."
根据声纳，“用Spring的@RequestMapping注解的方法可能有很多参数，封装是可能的。因此这些方法被忽略了。”
But sonar rules were not upgraded to skip the @POSTMapping, @PutMapping etc.. when spring introduced them. Ideally they are child implementations of @RequestMapping. The rules applicable to @RequestMapping should also apply to these.
但是声纳规则没有升级以跳过@POSTMapping、@PutMapping 等，当 spring 引入它们时。理想情况下，它们是@RequestMapping 的子实现。适用于@RequestMapping 的规则也应适用于这些。
Am planning to raise a ticket with SONAR on this. Will update the link once created.
我正计划在这方面与 SONAR 一起开票。创建后将更新链接。
For now you can edit your sonar rules or ignore these for now until sonar provides a solution part of their default ruleset.
现在，您可以编辑声纳规则或暂时忽略这些规则，直到声纳提供其默认规则集的解决方案部分。
回答by Coen Damen
In general this is a good rule. You should refactor to a Parameter Object or a Builder. However, I tend to ignore this rule when it concerns the creation of a domain model object (like an @Entity) or an immutable object where values are only passed in via the constructor.
一般来说，这是一个很好的规则。您应该重构为参数对象或构建器。但是，当涉及创建域模型对象（如@Entity）或仅通过构造函数传入值的不可变对象时，我倾向于忽略此规则。
