了解鱿鱼S00107:方法具有大于“ y”的“ x”参数

有没有看过像这样的java方法?

公共静态String CalculateAgeForPediatrics(String dob,String strEncDate,String strYearLetter,String strMonLetter,String strWeekLetter,String strDayLetter,String strHourLetter,String strMinLetter) 

除了明显的红色标记(例如方法名称中的大小写不正确)或不清楚的参数名称(例如strMonLetter)以外 ,SonarQube报告的问题之一是“ 方法具有8个参数,大于7个已授权参数”。

SonarQube将此错误归类为大脑超负荷,这确实是有道理的,参数多于7会使大脑超负荷(咳嗽讽刺)。 除了玩笑,参数太多通常表明您的方法过于依赖其他模块/类/对象。

当然,在上述方法中,我们不依赖太多内容,而仅依赖日期和格式这两个。 如果仔细观察,此方法取决于两个日期,而其他方法仅用于格式化后缀。 如果您不能相信它只是相信我,我已经看到了代码😉

因此,在这种情况下,绝对需要每个参数,但是如何避免拥有这么多参数!

有两种解决方法,一种是臭味,另一种是应该如何!

臭一第一

您可以使用哈希图对所有与格式相关的参数进行分组。 例如,该方法可以如下所示

 公共静态String CalculateAgeForPediatrics(String dob,String strEncDate,Map formattingPostFixes) 

你说这怎么了? 我说提前读!

映射是一种动态(运行时)数据结构,您失去了获得的所有编译时保护。 试想一下,如果有人用所有大写字母填充地图而程序期望它们位于较低的位置,将会发生什么? 否则,如果有人完全忘记添加一两个键,会发生什么! 不会发生编译错误,不会出现红色弯曲的下划线!

另外,除非您编写描述性注释,否则您希望API用户阅读您的代码,否则他们将无法知道此功能的期望。

我自己很喜欢Maps,但是将其替换为组参数听起来像是一个错误的用例。

应该如何—介绍参数对象:

我在Martin Fowler的Refactoring:改进现有代码的设计(Addison-wesley签名系列(Fowler))中了解了这种重构技术。

而不是使用Map,应该使用一类将相似的参数分组。 它不仅使方法签名更具可读性,而且还使您可以更好地控制每个参数。

例如:

 公共静态String CalculateAgeForPediatrics(String dob,String strEncDate,FormattingPostfixes postFixes); 
//在调用此方法时,这就是你要做的
FormattingPostFixes postFixes = new FormattingPostFixes(“ Yr”,“ Month(s)”,“ Week(s)”,“ Hr”,“ Min”);

有什么用? 首先,它使您的方法更具可读性。 而且,如果您长期将基元分组在一个类中,它们将帮助您避免代码重复。

它比地图更好吗? 好吧,它只是为您提供了编译时检查,这意味着您无法“忘记”其中一个后缀。 另外,您可以在新类中进行验证,例如,检查null或空字符串并采取适当的措施。

结论

当参数太多时,将相关参数分组在一个类中,并传递对象。

参考:

重构:改进现有代码的设计(Addison-wesley签名系列(Fowler))
马丁·福勒(Martin Fowler)的重构定义了成千上万的开发人员用来…的核心思想和技术 。www.amazon.i