3

Assume we have the next enum and I want to add equals(String) method to it, because other people that working with the same code usually make a mistake comparing enum with string using equals method.

public enum SomeEnum {
    CONSTANT1("DATABASE_CONSTANT1"),
    CONSTANT2("DATABASE_CONSTANT2");

    private final String databaseConstant;

    SomeEnum(String databaseConstant) {

        this.databaseConstant = databaseConstant;
    }

    public String getDatabaseConstant() {
        return databaseConstant;
    }

    public boolean equals(String databaseConstant) {
        return getDatabaseConstant().equals(databaseConstant);
    }
}

Question: are there any pitfalls in using the approach like this?

3
  • 3
    it's rather a problem of the people who make such mistakes Commented Feb 15, 2018 at 14:42
  • 3
    Adding new methods to work around coworkers novice coding mistakes feels wrong to me. Also this method will only work in some cases. It won't work when they are calling the equals method from the string method as in "DATABASE_CONSTANT1".equals(SomeEnum.CONSTANT1) or if the original equals method of the enum is called. Commented Feb 15, 2018 at 14:43
  • 2
    Honestly, it's cleaner to just throw an IllegalArgumentException from that method to avoid running into more problems later. Commented Feb 15, 2018 at 14:43

2 Answers 2

3

Some of the contracts bound to equals(..) would be violated. Especially symmetry. This can lead to all kinds of problems in the future.

https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#equals(java.lang.Object)

I recommend not to support the miss use of equals(..) 'other people' do.

To find code early that use equals(String ) you could do this:

@Deprecated
public boolean equals(String databaseConstant) {
  throw new IllegalArgumentException("Never use equals(String) for SomeEnumtype "); 
}

The @Deprecated will most IDE mark any call as a warning.


UPDATE
As davidxxx wrote in his comment & answer if you use e.g. sonar the warning of sonar would be sufficient to cope with your problem without adding the 'dead code' I offered as a solution above.

Sign up to request clarification or add additional context in comments.

3 Comments

While a clever trick, I find that adding dead code is not a good practice. Code quality tools are designed to.
@davidxxx: I agree, but this was the most practical thing I could come up with. If you can recommend a tool, which does the trick, Please share it with us.
Sonar does that : "rules.sonarsource.com/java/type/Bug/RSPEC-2159". My answer refers to.
3

Adding this method to avoid bad uses of a standard method as equals() is not advised.
Besides, even if you added this method in your SomeEnum class, you cannot and don't want to do the same thing in the String class!
So "DATABASE_CONSTANT1".equals(SomeEnum.DATABASE_CONSTANT1) is still possible and will not return what you would like.

I think that Lint and code analysis tool as Sonar are better to handle bad practices.

For example, Sonar defines the Silly equality checks should not be made bug rule.
This makes multiple checks about the equals() usage which you need :

comparing unrelated classes

Here is more detail about it :

Comparisons of dissimilar types will always return false. The comparison and all its dependent code can simply be removed. This includes:

comparing an object with null

comparing an object with an unrelated primitive (E.G. a string with an int)

comparing unrelated classes

comparing an unrelated class and interface

comparing unrelated interface types

comparing an array to a non-array

comparing two arrays

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.