rspec/rules/S1711/java/rule.adoc

65 lines
1.5 KiB
Plaintext

Just as there is little justification for writing your own String class, there is no good reason to re-define one of the existing, standard functional interfaces.
Doing so may seem tempting, since it would allow you to specify a little extra context with the name. But in the long run, it will be a source of confusion, because maintenance programmers will wonder what is different between the custom functional interface and the standard one.
== Noncompliant Code Example
----
@FunctionalInterface
public interface MyInterface { // Noncompliant
double toDouble(int a);
}
@FunctionalInterface
public interface ExtendedBooleanSupplier { // Noncompliant
boolean get();
default boolean isFalse() {
return !get();
}
}
public class MyClass {
private int a;
public double myMethod(MyInterface instance){
return instance.toDouble(a);
}
}
----
== Compliant Solution
----
@FunctionalInterface
public interface ExtendedBooleanSupplier extends BooleanSupplier { // Compliant, extends java.util.function.BooleanSupplier
default boolean isFalse() {
return !getAsBoolean();
}
}
public class MyClass {
private int a;
public double myMethod(IntToDoubleFunction instance){
return instance.applyAsDouble(a);
}
}
----
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
include::message.adoc[]
'''
== Comments And Links
(visible only on this page)
include::comments-and-links.adoc[]
endif::env-github,rspecator-view[]