我想减少开关盒的圈复杂度

我的代码是：

public String getCalenderName() {

switch (type) {

case COUNTRY:

return country == null ? name : country.getName() + HOLIDAY_CALENDAR;

case CCP:

return ccp == null ? name : ccp.getName() +" CCP" + HOLIDAY_CALENDAR;

case EXCHANGE:

return exchange == null ? name : exchange.getName() + HOLIDAY_CALENDAR;

case TENANT:

return tenant == null ? name : tenant.getName() + HOLIDAY_CALENDAR;

default:

return name;

}

}

此代码块的复杂度为16，并希望将其降低到10。

国家，ccp，交易所和租户是我的不同对象。 基于类型I将调用它们各自的方法。

"此代码复杂度为16，并且希望将其降低到10"为什么不将其降低到9？ 还是8？ 还是11？ 为什么16有问题？

根据我的声纳规则，我希望将其降低到10以下，如果我们可以进一步降低它，那就太好了。 @安迪·特纳

@AmarMagar您是否忘记在每种情况下或故意添加中断语句？ 我不确定添加中断语句是否有助于降低循环复杂性。

@克里希纳·昆塔拉(Krishna Kuntala)不需要break语句，因为在每种情况下他都将返回某些东西。

我相信这是一个Sonar警告。我认为Sonar警告不是必须执行的规则，而只是指导。您的代码块原为READABLE和MAINTAINABLE。它已经很简单，但是如果您真的想要更改它，可以尝试以下两种方法，看看复杂度是否降低了：

注意：我现在没有编译器，所以可能会出现错误，请对此表示抱歉。

第一种方法：

Map multipliers = new HashMap();

map.put("country", country);

map.put("exchange", exchange);

map.put("ccp", ccp);

map.put("tenant", tenant);

然后我们可以使用地图获取正确的元素

return map.get(type) == null ? name : map.get(type).getName() + HOLIDAY_CALENDAR;

第二种方法：

您所有的对象都有相同的方法，因此可以在其中添加Interface和getName()方法，并更改方法签名，例如：

getCalendarName(YourInterface yourObject){

return yourObject == null ? name : yourObject.getName() + HOLIDAY_CALENDAR;

}

已经尝试了第一种方法，但是无法在地图值上调用getName

然后使用第二种方法，引入一个带有getName()方法的新接口。如果您有共同的行为/方法，则应该使用多态的好处。

无论如何都以不同的方式找到了答案

据我所知，不要在switch语句中使用return语句。在switch语句后使用变量应用该逻辑。

创建一个用于检查空值的方法并从switch调用该方法，然后您将能够降低Cyclomatic Complexity

您可以用Dictionary>替换switch / case语句。

看看这个博客文章的最后一个例子

我认为您可以通过确保代码中的其他内容固定来降低复杂度。

举个例子：

case COUNTRY:

return country == null ? name : country.getName() + HOLIDAY_CALENDAR;

这意味着如果压延机类型为COUNTRY，则与压延机关联的国家/地区可能为null。这是您应设计避免的事情，因为我看不出为什么这可能是有效的情况。为什么您会有没有国家的国家日历？

因此，一旦为日历分配了type，请确保没有与日历关联的非空对象。这样，您的情况将像

case COUNTRY:

return country.getName() + HOLIDAY_CALENDAR;

将您的圈复杂度降低到5。

如果您的首要目标只是减少圈数的复杂性，则应针对每种获取名称的方式创建方法，如下所示。

public String getCalenderName() {

switch (type) {

case COUNTRY:

return getCountryName();

case CCP:

return getCcpName();

case EXCHANGE:

return getExchangeName();

case TENANT:

return getTenantName();

default:

return name;

}

}

private String getCountryName() {

return country == null ? name : country.getName() + HOLIDAY_CALENDAR;

}

private String getCcpName() {

return ccp == null ? name : ccp.getName() +" CCP" + HOLIDAY_CALENDAR;

}

private String getExchangeName() {

return exchange == null ? name : getName.toString() + HOLIDAY_CALENDAR;

}

private String getTenantName() {

return tenant == null ? name : getName.toString() + HOLIDAY_CALENDAR;

}

请注意，在您的特定示例中，我假设您有1个类收集(至少)4个非常相似的行为。重构无疑会更有意义，例如具有一个基本实现(是否抽象)以及其他4个继承的类。

当然，如果您不想让声纳抱怨，请添加javadoc;)

如果您的对象：国家/地区，cpp，交易所和租户共享同一接口，例如您可以使用ObjectWithGetName重构代码，如下所示：

public String getCalenderName() {

ObjectWithGetNameMethod calendarType = null;

switch (type) {

case COUNTRY:

calendarType = country;

break;

case CCP:

calendarType = cpp;

break;

case EXCHANGE:

calendarType = exchange;

break;

case TENANT:

calendarType = tenant;

break;

default:

calendarType = null;

}

return (calendarType != null ? (calendarType.getName() + HOLIDAY_CALENDAR) : name);

}

我也认为将开关切换到单独的方法会很好，因为看起来巫婆会在许多不同的地方使用。

该解决方案不起作用，因为国家/地区，抄送，交易所和租户是不同的实体。因此，在调用getName方法时，我必须使用它们各自的对象来调用方法。

您可以删除所有空比较，并在切换大小写之前对其进行检查。在这种情况下，复杂度将减少4倍或更多。

尝试仍然无法减少

public String getName() {

if (type == null) {

return name;

}

if (type == BusinessCalendarType.COUNTRY) {

return country == null ? name : country.getName() + HOLIDAY_CALENDAR;

} else if (type == BusinessCalendarType.CCP) {

return ccp == null ? name : ccp.getName() +" CCP" + HOLIDAY_CALENDAR;

} else if (type == BusinessCalendarType.EXCHANGE) {

return exchange == null ? name : exchange.getName() + HOLIDAY_CALENDAR;

} else if (type == BusinessCalendarType.TENANT)  {

return tenant == null ? name : tenant.getName() + HOLIDAY_CALENDAR;

} else {

return name;

}

}

这对我有用

这在功能上是错误的。 swicht语句中的默认值不对应于type == null

实际上type是一个Enum，并且肯定会返回这4个值之一或仅返回null。在我的问题中，我写了默认声明，这是因为声纳警告。反正你是对的。根据您的建议，我已经更改了此答案。

您只是为了使声纳中的警告规则更难阅读而使相对(人类)可读的功能变得更加难以理解...