Rename field "NOTIFY" to prevent any misunderstanding/clash with method "notify" defined in superclass "java.lang.Object". Open
String NOTIFY = "NOTIFY";
- Read upRead up
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Move constants defined in this interfaces to another class or enum. Open
public interface SchemeConstantsN {
- Read upRead up
- Exclude checks
According to Joshua Bloch, author of "Effective Java":
The constant interface pattern is a poor use of interfaces.
That a class uses some constants internally is an implementation detail.
Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface,
all of its subclasses will have their namespaces polluted by the constants in the interface.
This rule raises an issue when an interface consists solely of fields, without any other members.
Noncompliant Code Example
interface Status { // Noncompliant int OPEN = 1; int CLOSED = 2; }
Compliant Solution
public enum Status { // Compliant OPEN, CLOSED; }
or
public final class Status { // Compliant public static final int OPEN = 1; public static final int CLOSED = 2; }